Um belo dia você está alimentando seu banco de dados com novos acessórios e você recebe a informação do seu chefe que dois deles são incompatíveis entre si. Digamos direção hidráulica e direção elétrica. Você não pode deixar o cliente escolher os dois, logo, você deverá restringir isso no seu software.
Você decide por não remodelar sua estrutura e prefere fazer um pequeno "conserto" na sua programação:
Entretanto, suponha que para sua infelicidade, cada dia que se passa começam a surgir mais e mais produtos que se encaixam na condição de incompatibilidade e você se vê obrigado a encher seu código com zilhares de if's, a primeira coisa que se percebe nesse ponto é que você se tornou escravo do seu código, pois toda vez que novos acessórios com incompatibilidade são inseridos você deve alterá-lo.
Cansado de mexer no seu código a cada novo acessório você decide remodelar sua estrutura, já que seu programa não deve apenas atender as necessidades que ele atendia quando ele foi projetado, o programa precisa evoluir para atender novas necessidades e isso exige um remodelagem. Uma opção seria alterar sua classe Acessório, deixando ela assim:
Foi adicionado um atributo grupo que indica quais acessórios pertencem a um mesmo grupo e portanto não podem ser usados ao mesmo tempo. A parte do código que possuía os inúmeros if's ficaria da seguinte maneira:
Modelando dessa maneira, não mais é necessário alterar o código para indicar quais acessórios são incompatíveis, basta cadastrá-los no banco de dados dentro de um mesmo grupo, então toda vez que um acessório for selecionado os acessórios incompatíveis serão removidos.
O polimorfismo já foi citado na resposta aceita, mas preferi citá-lo novamente pois quis criar um exemplo mais enxuto. O segundo ninguém havia citado. – Math♦ 29/04/14 às 0:23
Acho que é pq o 2o. ñ elimina o if:) Só está em outro lugar. É como o exemplo do for do Luiz Vieira, não eliminou o for, só trocou de lugar. Eu tinha votado nela por causa da parte do polimorfismo clássico. De uma certa forma o segundo é um polimorfismo do objeto mas que só dá certo em situações específicas. Não acho que o objetivo de eliminar o if seja este. De qualquer forma dá para fazer de forma mais flexível com lambda. Deu até vontade de responder pq ainda ñ tem resposta com isto. Mas não é a solução correta. A sua resposta, do carlosrafaelgn e do hugomg deveriam ter + votos. – Maniero♦ 9/03/15 às 14:20
@bigown sim, eu apenas troquei o if de lugar, se tiverem 1000 acessórios que a condição deve ser checada o if será executado 1000 vezes, mas ele só é escrito na linha do código uma única vez, isso junto com o novo campo grupo do objeto refletem em uma manutenibilidade infinitamente melhor pois o código não precisará mudar cada vez que o BD for atualizado ;-) Sobre o lambda, estou meio desatualizado e não sei exatamente do que se trata, se compartilhar uma resposta pode atualizar quem estiver perdido assim que nem eu :) – Math♦ 11/03/15 às 11:41