O grupo no qual você está postando é um grupo da Usenet. As mensagens postadas neste grupo farão com que o seu e-mail fique visível para qualquer pessoa na internet.
-- Thiago N Ramalho.
Estagiário da DATAPREV - Empresa de Tecnologia e Informações da
Previdência Social
Bacharelando em Sistemas de Informação, 7º Período
"O sangue em nossas veias, nos permite viver. O sangue nos nossos
sonhos, nos faz vencer!"
> --
> Thiago N Ramalho.
> Estagiário da DATAPREV - Empresa de Tecnologia e Informações da
> Previdência Social
> Bacharelando em Sistemas de Informação, 7º Período
> "O sangue em nossas veias, nos permite viver. O sangue nos nossos
> sonhos, nos faz vencer!"
-- Márcio Dorimar da Silva Gomes
Stefanini IT Solutions (Brasília/DF)
Graduado em Ciências da Computacao - DSC - UFCG
> --
> Thiago N Ramalho.
> Estagiário da DATAPREV - Empresa de Tecnologia e Informações da
> Previdência Social
> Bacharelando em Sistemas de Informação, 7º Período
> "O sangue em nossas veias, nos permite viver. O sangue nos nossos
> sonhos, nos faz vencer!"
Talvez o exemplo que está dando não dê subsídio suficiente para sabermos a situação.
AFinal de contas, se o bloco 1 e 2 irão acontecer independentemente de ser a opção A ou B não há necessidade real de fazer mais do que um IF.
Porém, aquilo que parece estar fazendo está mais para um switch case do que if.... pois vc pode dar o break e continuar a sequencia de codigos que precisar depois....
From: flavio.bar...@gmail.com
Date: Sun, 8 Nov 2009 12:43:57 -0200
Subject: [PBJUG] Re: Estruturando condicionais e blocos repetidos de código
To: pbjug@googlegroups.com
Thiago, existem códigos entre os blocos1 e 2. Não pode simplesmente agrupá-los num mesmo condicional. :-)
--
Thiago N Ramalho.
Estagiário da DATAPREV - Empresa de Tecnologia e Informações da
Previdência Social
Bacharelando em Sistemas de Informação, 7º Período
"O sangue em nossas veias, nos permite viver. O sangue nos nossos
sonhos, nos faz vencer!"
Onde tem bloco1 representa um mesmo trecho de código.
O mesmo vale para o bloco2. São códigos repetidos.
Dá pra imaginar como sendo duas chamadas de método.
Citando Cleber:
> AFinal de contas, se o bloco 1 e 2 irão acontecer independentemente de ser
> a opção A ou B não há necessidade real de fazer mais do que um IF.
Claro que há necessidade.
Primeiro o bloco1 deve ser executado (se A ou B for satisfeito).
Depois, se A, então executo um código específico (representando por
reticências). Senão, se for B, eu executo outro código.
Por fim, se A ou B for satisfeito, eu executo o bloco2.
Mas enfim, if com outro if aninhado dentro do else normalmente significa que você queria um switch, mas como o switch do java é basicamente inútil você termina indo pra o caminho mais simples.
Se predicados não resolvem o seu problema, eu realmente não acho que hajam muitas opções. O problema de colocar os ifs fora do else é o custo em processamento que pode ser grande dependendo do custo de execução de cada condição.
> Onde tem bloco1 representa um mesmo trecho de código. > O mesmo vale para o bloco2. São códigos repetidos. > Dá pra imaginar como sendo duas chamadas de método.
> Citando Cleber:
>> AFinal de contas, se o bloco 1 e 2 irão acontecer independentemente de ser >> a opção A ou B não há necessidade real de fazer mais do que um IF.
> Claro que há necessidade. > Primeiro o bloco1 deve ser executado (se A ou B for satisfeito). > Depois, se A, então executo um código específico (representando por > reticências). Senão, se for B, eu executo outro código. > Por fim, se A ou B for satisfeito, eu executo o bloco2.
Na real eu não tenho problema, só queria ouvir opiniões sobre como vcs
estruturariam um código desse tipo. Argumentos, prós, contras etc...
Imagine exatamente os dois códigos abaixo. Exatamente como está.
O fluxo de execução deve ser mantido.
Como você o organizaria? Da forma 1, da forma 2, de outra forma? Por que?
Note que os dois códigos abaixo fazer exatamente a mesma coisa para todas as
possibilidades de A e B.
> Mas enfim, if com outro if aninhado dentro do else normalmente
> significa que você queria um switch, mas como o switch do java é
> basicamente inútil você termina indo pra o caminho mais simples.
> Se predicados não resolvem o seu problema, eu realmente não acho que
> hajam muitas opções. O problema de colocar os ifs fora do else é o
> custo em processamento que pode ser grande dependendo do custo de
> execução de cada condição.
> > Onde tem bloco1 representa um mesmo trecho de código.
> > O mesmo vale para o bloco2. São códigos repetidos.
> > Dá pra imaginar como sendo duas chamadas de método.
> > Citando Cleber:
> >> AFinal de contas, se o bloco 1 e 2 irão acontecer independentemente de
> ser
> >> a opção A ou B não há necessidade real de fazer mais do que um IF.
> > Claro que há necessidade.
> > Primeiro o bloco1 deve ser executado (se A ou B for satisfeito).
> > Depois, se A, então executo um código específico (representando por
> > reticências). Senão, se for B, eu executo outro código.
> > Por fim, se A ou B for satisfeito, eu executo o bloco2.
> Na real eu não tenho problema, só queria ouvir opiniões sobre como vcs
> estruturariam um código desse tipo. Argumentos, prós, contras etc...
> Imagine exatamente os dois códigos abaixo. Exatamente como está.
> O fluxo de execução deve ser mantido.
> Como você o organizaria? Da forma 1, da forma 2, de outra forma? Por que?
> Note que os dois códigos abaixo fazer exatamente a mesma coisa para todas as
> possibilidades de A e B.
>> Mas enfim, if com outro if aninhado dentro do else normalmente
>> significa que você queria um switch, mas como o switch do java é
>> basicamente inútil você termina indo pra o caminho mais simples.
>> Se predicados não resolvem o seu problema, eu realmente não acho que
>> hajam muitas opções. O problema de colocar os ifs fora do else é o
>> custo em processamento que pode ser grande dependendo do custo de
>> execução de cada condição.
>> > Onde tem bloco1 representa um mesmo trecho de código.
>> > O mesmo vale para o bloco2. São códigos repetidos.
>> > Dá pra imaginar como sendo duas chamadas de método.
>> > Citando Cleber:
>> >> AFinal de contas, se o bloco 1 e 2 irão acontecer independentemente de
>> >> ser
>> >> a opção A ou B não há necessidade real de fazer mais do que um IF.
>> > Claro que há necessidade.
>> > Primeiro o bloco1 deve ser executado (se A ou B for satisfeito).
>> > Depois, se A, então executo um código específico (representando por
>> > reticências). Senão, se for B, eu executo outro código.
>> > Por fim, se A ou B for satisfeito, eu executo o bloco2.
-- Thiago N Ramalho.
Estagiário da DATAPREV - Empresa de Tecnologia e Informações da
Previdência Social
Bacharelando em Sistemas de Informação, 7º Período
"O sangue em nossas veias, nos permite viver. O sangue nos nossos
sonhos, nos faz vencer!"
Ah, caiu a ficha agora, quando Java tiver suporte a closures vai ser
mais simples de fazer isso ;D
Eu faria do jeito 2, acho mais fácil de entender, mas não vejo
vantagens em nenhum dos dois. Acho que do jeito que o Thiago comentou
também fica bem mais legível e evita os ifs de uma linha.
> Na real eu não tenho problema, só queria ouvir opiniões sobre como vcs
> estruturariam um código desse tipo. Argumentos, prós, contras etc...
> Imagine exatamente os dois códigos abaixo. Exatamente como está.
> O fluxo de execução deve ser mantido.
> Como você o organizaria? Da forma 1, da forma 2, de outra forma? Por que?
> Note que os dois códigos abaixo fazer exatamente a mesma coisa para todas as
> possibilidades de A e B.
>> Mas enfim, if com outro if aninhado dentro do else normalmente
>> significa que você queria um switch, mas como o switch do java é
>> basicamente inútil você termina indo pra o caminho mais simples.
>> Se predicados não resolvem o seu problema, eu realmente não acho que
>> hajam muitas opções. O problema de colocar os ifs fora do else é o
>> custo em processamento que pode ser grande dependendo do custo de
>> execução de cada condição.
>> > Onde tem bloco1 representa um mesmo trecho de código.
>> > O mesmo vale para o bloco2. São códigos repetidos.
>> > Dá pra imaginar como sendo duas chamadas de método.
>> > Citando Cleber:
>> >> AFinal de contas, se o bloco 1 e 2 irão acontecer independentemente de
>> >> ser
>> >> a opção A ou B não há necessidade real de fazer mais do que um IF.
>> > Claro que há necessidade.
>> > Primeiro o bloco1 deve ser executado (se A ou B for satisfeito).
>> > Depois, se A, então executo um código específico (representando por
>> > reticências). Senão, se for B, eu executo outro código.
>> > Por fim, se A ou B for satisfeito, eu executo o bloco2.
vai ter mais linhas, mas parece ser mais objetivo pro processador...
testa se é A, se não é ja pula logo pro 2º teste... Isso é mais objetivo do que testar se é A ou B pra executar um determinado codigo e dependendo de quem for executar outro...
e a clausula else no fim é pra q vc use caso não seja nenhum dos dois...
porém, pelo jeito existe a possibilidade de ter um C ou um D ou sabe-se lá mais o que...
dai volto pra ideia de q um switch case é melhor...
o siwtch case dispensa o primeiro condicional de ver se é um ou outro... entrou nele ele verifica quem é e executa o que se pede de acordo com quem eh... e tem o default... se entrar nele e não for nada do que se espera, faz o default...
From: flavio.bar...@gmail.com
Date: Sun, 8 Nov 2009 14:05:02 -0200
Subject: [PBJUG] Re: Estruturando condicionais e blocos repetidos de código
To: pbjug@googlegroups.com
Na real eu não tenho problema, só queria ouvir opiniões sobre como vcs estruturariam um código desse tipo. Argumentos, prós, contras etc...
Imagine exatamente os dois códigos abaixo. Exatamente como está.
O fluxo de execução deve ser mantido.
Como você o organizaria? Da forma 1, da forma 2, de outra forma? Por que?
Note que os dois códigos abaixo fazer exatamente a mesma coisa para todas as possibilidades de A e B.
Código 1:
if (A) { bloco1(); // ... bloco3(); bloco2();} else { if (B) { bloco1(); // ... bloco4(); bloco2(); }}
Código 2:
if (A || B) bloco1();if (A) { // ... bloco3();} else if (B) { // ... bloco4();}if (A || B) bloco2();
Mas enfim, if com outro if aninhado dentro do else normalmente
significa que você queria um switch, mas como o switch do java é
basicamente inútil você termina indo pra o caminho mais simples.
Se predicados não resolvem o seu problema, eu realmente não acho que
hajam muitas opções. O problema de colocar os ifs fora do else é o
custo em processamento que pode ser grande dependendo do custo de
execução de cada condição.
> Onde tem bloco1 representa um mesmo trecho de código.
> O mesmo vale para o bloco2. São códigos repetidos.
> Dá pra imaginar como sendo duas chamadas de método.
> Citando Cleber:
>> AFinal de contas, se o bloco 1 e 2 irão acontecer independentemente de ser
>> a opção A ou B não há necessidade real de fazer mais do que um IF.
> Claro que há necessidade.
> Primeiro o bloco1 deve ser executado (se A ou B for satisfeito).
> Depois, se A, então executo um código específico (representando por
> reticências). Senão, se for B, eu executo outro código.
> Por fim, se A ou B for satisfeito, eu executo o bloco2.
> Na real eu não tenho problema, só queria ouvir opiniões sobre como vcs
> estruturariam um código desse tipo. Argumentos, prós, contras etc...
> Imagine exatamente os dois códigos abaixo. Exatamente como está.
> O fluxo de execução deve ser mantido.
> Como você o organizaria? Da forma 1, da forma 2, de outra forma? Por que?
> Note que os dois códigos abaixo fazer exatamente a mesma coisa para todas
> as possibilidades de A e B.
>> Mas enfim, if com outro if aninhado dentro do else normalmente
>> significa que você queria um switch, mas como o switch do java é
>> basicamente inútil você termina indo pra o caminho mais simples.
>> Se predicados não resolvem o seu problema, eu realmente não acho que
>> hajam muitas opções. O problema de colocar os ifs fora do else é o
>> custo em processamento que pode ser grande dependendo do custo de
>> execução de cada condição.
>> > Onde tem bloco1 representa um mesmo trecho de código.
>> > O mesmo vale para o bloco2. São códigos repetidos.
>> > Dá pra imaginar como sendo duas chamadas de método.
>> > Citando Cleber:
>> >> AFinal de contas, se o bloco 1 e 2 irão acontecer independentemente de
>> ser
>> >> a opção A ou B não há necessidade real de fazer mais do que um IF.
>> > Claro que há necessidade.
>> > Primeiro o bloco1 deve ser executado (se A ou B for satisfeito).
>> > Depois, se A, então executo um código específico (representando por
>> > reticências). Senão, se for B, eu executo outro código.
>> > Por fim, se A ou B for satisfeito, eu executo o bloco2.
|
