Composicao ao invés de heranca mesmo quando temos uma relacao IS-A

This message was edited 3 times. Last update was at 24/08/2011 20:43:54

Já devem fazer uns 6 anos que vejo o SAOJ reclamar de testes unitários com herança..(Com o meu antigo login do fórum).

Faz 4 anos que larguei mão de ser desenvolvedor Java, agora desenvolvo somente utilitários em Java ultimamente, pois estou mais focado em na minha especialidade.

Estou montando um utilitário para rodar rotinas ICommand segui a seguinte arquitetura.

JFD - JFormDev -> View (Plugin do ecplise proprietário)
BackingBean -> Suportar a minha view com propriedades de tela e setting/getting
Controller <-> Runner -> Nem preciso Falar
DAO -> Idem a acima
Entity -> Estou extraindo dados só para apresentação via JPA.

A minhas entities são compátiveis com a visualização, então para simplificar criei uma Interface para crossing entre as camadas, são 15 entidades originadas de tabelas diferentes, mas os dados que preciso são comuns, existem algumas regras no comportamento que são diferentes. Por este motivo adotei a interface.

Há diferenças nas linhas de comando como nos casos abaixo:

Exemplo 1:

Exemplo 2:

Ficou bem clean para o meu Runner uma classe que criei para executar meus comandos.

Eu fiz uma primeira tentativa de usar o polimorfismo com Herança anteriormente, como naquela altura não havia imaginado que existiriam peculiariedades em cada linha de comando criei um metódo e fui herdando. Quando vi já estava feita a bagunça fiquei sobreescrevendo o original. Resolvi mudar para abstract e depois vi que era melhor ter usado uma interface mesmo.

No meu caso composição não ficaria legal, ficaria um pouco ruim lidar com as N fontes de dados. Esse seria um caso onde é mais interessante a abordagem por interfaces.

Antes de criar um metódo para ser herdado vc precisa saber oq está fazendo, senão vc acaba obrigando todo mundo a dar overwrite e no fim das contas ninguem mais sabe oq está valendo. A abordagem por interfaces é superior, acho que existem alguns casos que é interessante criar classes como as Support que implementam algumas interfaces, mas na maioria dos casos acho que o beneficio é baixo.

Sobre interfaces, existe essa entrevista bastante interessante com o Erich Gamma.
http://www.artima.com/lejava/articles/designprinciples.html

This message was edited 11 times. Last update was at 25/08/2011 14:53:28

O mais importante, na minha opinião, é uma boa FUNDACÃO para o seu sistema. Explico o que seja isso mais adiante...

Fico bastante chateado quando pego um sistema feito na base do PAU, ou seja, o sistema não tinha uma boa fundacão e código foi escrito na base do pau.

Resultado: a coisa funciona muito bem, pois o cara que fez era competente e got the job done. Mas dói os zoios olhar para a coisa.

Com uma boa fundacão, vc até terá um sistema ou outro baguncado, porque o cara criou muitos métodos protected, ou porque o código do cara é ruim mesmo.

Mas o CORE vai estar bonito. A fundacão vai garantir que a coisa fique no controle.

Um código sem essa fundacao é mais ou menos como um homem sem integridade.

Por que eu contei essa história?

Porque pelo menos pra Java, eu acho que uma fundacão baseado em heranca com classes abstratas é melhor do que uma sem heranca baseada em composicao.

Uma fundacao não é só isso. É tb prnicipalmente interfaces e componentes do seu sistema. Aí que entra a ARTE e a EXPERIENCIA. O cara tem que saber quais interfaces criar para melhor descrever o problema e as interacoes entre as classes.

Ex:

Parser, ParserListener, Client, ClientListener, AbstractUDPClient, AbstractTCPClient, e por aí vai.

Se o cara erra no comeco, na fundacao, pode chamar o melhor programador do mundo que vai ser tudo uma bagunca de código.

E para concluir:

Repare que todo o FRAMEWORK nada mais é do que uma fundacao, ou seja, uma API para abstrair algo complexo por baixo.

A arte não está em programar as linhas de código. Isso qualquer cara com QI reazoável pode fazer.

A arte está em fazer uma API simples que permita com que as pessoas que forem usar o seu framework possam ter uma boa fundacao para que os seus código não fiquem zoneados.

O que eu mais gosto de fazer não é escrever código, mas desenvolver APIs. É o caso do Space4J x Prevayler, ou a do Struts2 x Mentawai.

Só que para fazer a sua API funcionar, ou seja, para que vc prove que sua fundacão funciona, que é simples e coesa, vc tem que escrever bastante código por baixo.

E minha frase favorita: "A perfeição é alcançada, não quando não existe nada mais para se acrescentar, mas quando não existe mais nada para se retirar." (Antoine de Saint-Exupéry)

This message was edited 1 time. Last update was at 25/08/2011 14:28:49

Considerando duas situações extremas:

Eu prefiro um código
a) bem refatorado, bem modular e com classes coesas, mas completamente sem testes automáticos,
do que:
b) um código mal escrito e com 100% de cobertura de testes automáticos.

Motivos:
1. Será fácil escrever testes e manter o código coeso (com "boa fundação");
2. Provavelmente o código macarrônico terá também testes igualmente macarrônicos. Ambos terão que ser reescritos.

Já notei que o número de erros em código bem escrito realmente é imensamente menor do que o de código mal escrito, tenha você práticas de testes ou não.
Os testes auxiliam em evitar a reincidência do erro, especialmente durante uma refatoração. Auxiliam também na prevenção de erros mas, do contrário que livros sobre testes vendem, não fazem milagres.

Código mal escrito é sempre código mal escrito.

This message was edited 3 times. Last update was at 25/08/2011 14:58:50

ViniGodoy wrote:
Código mal escrito é sempre código mal escrito.

Acho que me expressei mal no início do meu post, mas já editei lá.

Não estou falando de uma pessoa sem fundacao, mas de um sistema sem uma boa fundacao.

Os extremos são:

1 - Um código bem escrito em cima de uma fundacao ruim.

2- Um código mal escrito em cima de uma boa fundacao.

Eu vou SEMPRE preferir a opcao 2).

A fundacão não são os testes, apesar de eu entender que tem muita gente que usa isso como fundacao. Só porque um sistema funciona e não possui bugs, ou seja, só porque todos os 1231231232131 testes unitários passaram, não significa que o código está bem feito, apenas que funciona. E como eu falei, qualquer um com QI analítico mediano consegue fazer um código que funciona.

E aqui no que vc falou:

a) bem refatorado, bem modular e com classes coesas, mas completamente sem testes automáticos,
do que:
b) um código mal escrito e com 100% de cobertura de testes automáticos.

Vou sempre preferir a).

Quando a FUNDACAO comeca errada, não há santo que faca milagre.

O CORE, de uma pessoa, de um sistema, de um prédio, é o mais importante.

saoj, desculpe a pegunta direta, mas por que vc não gosta dos testes?

P.S Ótimo topico.

flws

This message was edited 2 times. Last update was at 25/08/2011 21:17:49

fantomas wrote:saoj, desculpe a pegunta direta, mas por que vc não gosta dos testes?

P.S Ótimo topico.

flws

Melhor deixar essa discussão para outro tópico, né? Se vc googlar vai encontrar uns pouquíssimos gatos pingados que pensam como eu. Eu sou a favor de teste automatizado. Acho bem legal. Mas teste automatizado (feito via JUnit) é MUITO DIFERENTE de teste UNITÁRIO.

O melhores sistema que vi na vida não tinha quase nenhum teste unitário. Os piores estavam cheios de testes unitários, daqueles que fazem o build demorar 20 minutos rodando os 1123123123 testes.

Um maluco que achei no Google: http://www.contrariansoftware.com/2008/11/unit-testing-sucks.html

There is also the theory that unit testing ensures that, when you change some code, it doesn?t break other code. Well that?s only true if it breaks something in a way anticipated by the unit test. But you have to ask yourself, why is your project architected in such a way that it?s so susceptible to a small code change in one place breaking code elsewhere? No, it?s not because of ?tight coupling? or failure to follow object oriented design patterns. It?s because of bad planning, and bad developers who confuse unit testing with quality coding. It?s because too many developers are working on the same parts of the project. Too many programmers spoil the code just as surely as too many cooks spoil the broth. The only way to create a quality big project is to divide it up into independent small projects.

Oi saoj, valeu pela resposta.

Concordo com vc, este papo acho que vale um outro tópico.

Fiz a pergunta porque vc foi o primeiro (que eu vi) que teve coragem de falar isso neste forum e a idéia me deixou bem curioso tambem. Quando comecei a programar haviam bem menos recursos e ferramentas em termos de software do que hoje para auxiliar na produção de códigos; debuggers acho que nem existiam só para ter ideia. Quem queria um código com mais qualidade deveria se valer de um esforço próprio lançando mão de conhecimentos técnicos mais consistente, sem falar da experiencia.

Não tenho resistencia em utilizar testes, eu até utilizo mas não como vc diz que é feito por aí de forma ostensiva a ponto de criar scripts de execução automática e etc...apenas em coisas bem pontuais. Eu até me culpava um pouco por ainda não aplicar isto (força do modismo), até o dia de hoje rsrsrs.

Vou fazer algumas pesquisas sobre o assunto.

Abraços

Virtual Machine Man Membro desde: 07/03/2007 15:58:16 Mensagens: 518 Offline

fantomas wrote:Oi saoj, valeu pela resposta.

Concordo com vc, este papo acho que vale um outro tópico.

Fiz a pergunta porque vc foi o primeiro (que eu vi) que teve coragem de falar isso neste forum e a idéia me deixou bem curioso tambem. Quando comecei a programar haviam bem menos recursos e ferramentas em termos de software do que hoje para auxiliar na produção de códigos; debuggers acho que nem existiam só para ter ideia. Quem queria um código com mais qualidade deveria se valer de um esforço próprio lançando mão de conhecimentos técnicos mais consistente, sem falar da experiencia.

Não tenho resistencia em utilizar testes, eu até utilizo mas não como vc diz que é feito por aí de forma ostensiva a ponto de criar scripts de execução automática e etc...apenas em coisas bem pontuais. Eu até me culpava um pouco por ainda não aplicar isto (força do modismo), até o dia de hoje rsrsrs.

Vou fazer algumas pesquisas sobre o assunto.

Abraços

Hmm, nao tao rapido.

There is also the theory that unit testing ensures that, when you change some code, it doesn?t break other code. Well that?s only true if it breaks something in a way anticipated by the unit test.

Esta pseudo seguranca é apenas um dos beneficios dos testes, nao o maior deles. E mesmo que ele tenha quebrado de uma forma que voce nao havia previsto e o erro so tenha sido descoberto em producao, ainda assim, agora voce vai poder adicionar mais um teste e garantir que esta falha nao ocorrera novamente. Sem os testes voce nao garante que daqui algum tempo alguem fara uma alteracao que resultara no mesmo erro.

But you have to ask yourself, why is your project architected in such a way that it?s so susceptible to a small code change in one place breaking code elsewhere? No, it?s not because of ?tight coupling? or failure to follow object oriented design patterns. It?s because of bad planning,

Teste faz parte do planning. "Planning" em grande parte das vezes é especulação. De fato os testes por si só nao levam a um bom código, mas nao consigo imaginar de que forma eles possam atrapalhar quem tem esta capacidade.

and bad developers who confuse unit testing with quality coding. It?s because too many developers are working on the same parts of the project. Too many programmers spoil the code just as surely as too many cooks spoil the broth. The only way to create a quality big project is to divide it up into independent small projects.

É dificil de responder a uma "acusação" dessas. "Too many", "big project"? Quanto é too many? O q é um big project? Se voce disser que dez programadores trabalhando em códigos bem proximos, isto é too many. Se voce disser que dois ou tres, isto é o ideal.

Os testes são uma forma de projetar o código. Se vai ficar bom ou ruim é uma outra historia, isto vai depender mais dos programadores do que dos testes. Mas o que eu tenho visto é que programadores que não conseguem projetar bons códigos, não são capazes de manter os testes por muito tempo. Porque sem duvidas, os testes tem contra si, a necessidade de um cuidado muito grande ou eles viram uma massa disforme que toma mais tempo para ser manuseada do que o proprio codigo da aplicacao. E ai eles perdem o sentido.

Agora, este paragrafo me pareceu obra de alguem que defende o big design upfront, que gosta de dividir bem o trabalho e planejar com cuidado.

Mas e as consequencias disso? Quando voce tem o trabalho "bem dividido", isto é, cada um trabalhando pacientemente em uma coisa separada, voce leva mais tempo entre o inicio e o fim de uma funcionalidade. Quando voce tem dois ou tres programadores trabalhando numa mesma parte do código voce vai ter o teu processo cuspindo funcionalidade pronta para ser testada, integrada e entregue em ciclos muito curtos. O que tem muito mais valor do que um planejamento especulativo que cria a ilusão de qualidade.

Notícias, artigos e o maior fórum brasileiro sobre Java