Pq os teste unitários não são tão populares!

Considerando que Swing é só interface gráfica -que deve ser testada mas não necessariamente com unit tests- eu não entendi o problema. De qualquer modo, criar 'um design lindo' vai envolver refactoring logo a aplicação mal-projetada vai ser consertada eventualmente.

Os argumentos usados em discussões como esta me levam a repetir o que sempre digo: independentemente da linguagem ser estruturada ou OO ou outra porra qualquer, "POG" não é "Programação Orientada a Gambiarras", mas sim "Programador Orientado a Gambiarras".

louds wrote:
Qual o problema de arquivos de 10mil linhas? Não vejo problema nisso. Minhas teclas preferidas são page-up e page-down. Muito mais rápido e produtivo que ficar trocando de arquivo o tempo todo.

Concordo plenamente !

Inclusive seria bom que os amantes da OO evitassem argumentos que possam sugerir que o que apreciam mesmo é a POPE (Programação Orientada a Preguiça de Escrever).

pcalcado wrote:Considerando que Swing é só interface gráfica -que deve ser testada mas não necessariamente com unit tests- eu não entendi o problema. De qualquer modo, criar 'um design lindo' vai envolver refactoring logo a aplicação mal-projetada vai ser consertada eventualmente.

Swing foi só um exemplo. Utilize no lugar dele qualquer outro framework mal-projetado que você seja forçado a usar sem poder alterar uma única vírgula no código-fonte deste.

victorwss wrote:
Swing foi só um exemplo. Utilize no lugar dele qualquer outro framework mal-projetado que você seja forçado a usar sem poder alterar uma única vírgula no código-fonte deste.

Eu ainda não entendi o problema. Se você não pode testar o componente em si basta isolá-lo. Ao invés de fazer sua classe estender isso faça uma classe que estende e apenas delega para a sua, que contêm a lógica de fato e é bem testada. Existem dezenas de padrões e técnicas para fazer isso.

This message was edited 1 time. Last update was at 03/06/2008 10:35:58

pcalcado wrote:

victorwss wrote:
Swing foi só um exemplo. Utilize no lugar dele qualquer outro framework mal-projetado que você seja forçado a usar sem poder alterar uma única vírgula no código-fonte deste.

Eu ainda não entendi o problema. Se você não pode testar o componente em si basta isolá-lo. Ao invés de fazer sua classe estender isso faça uma classe que estende e apenas delega para a sua, que contêm a lógica de fato e é bem testada. Existem dezenas de padrões e técnicas para fazer isso.

Então, é aí que está a difereneça entre o bom e o excelente arquiteto:
Criar classes com alta coesão, baixo acoplamento, POGless mesmo estando em cima de um framework ruim e limitado, e não apenas criar classes com alta coesão, baixo acoplamento e POGless.

O Leonardo falou que uma classe com 100 métodos é um design ruim é deve ser evitado em primeiro lugar quando comentava sobre algum argumento de que isso prejudicaria testabilidade. Você respondeu dizendo que sistemas legados podem ter 100 métodos. Eu respondi dizendo que istemas legados devem ser refatorados e/ou isolados.

Podemos dizer então que você concorda com o Leonardo?

This message was edited 3 times. Last update was at 03/06/2008 10:57:39

Imagine implementar JPasswordField extends Object via composição com JTextField, seria loucura. Além de que isso não funcionaria porque existem muitos lugares que iriam testar se o seu JPasswordField extends Component, JComponent ou qualquer coisa assim.

Teria que haver uma interface Component. É o mesmo caso da interface Object que eu ilustrei num post anterior, mas o seu exemplo é mais um que diz como seria ingrata a vida do programador Java sem herança. Acho que a questão se herança é importante ou não já foi esclarecida. Herança é muito importante na linguagem Java e se vc não acredita em mim pelo menos acredite na implementação do Joshua Bloch de collections, que utilizou herança quando poderia ter utilizado interfaces + composição + delegação.

Acho que vc deve preferir composição ao invés de herança quando não há hierarquia, quando vc não vai precisar passar o filho como pai para sistemas legados ou outros métodos do seu sistema que esperam o pai e podem fazer uso de polimorfismo recebendo o filho.

Um PastorAlemão conter Cachorro ao invés de herdar Cachorro me parece totalmente errado. PastorAlemão é um Cachorro e muito provavelmente vc vai querer passá-lo para métodos que recebem Cachorro e usam polimorfismo. Isso em Java, onde o tipo é fundamental. Em Ruby seria outra história...

Agora se existe uma interface Cachorro, como existe uma interface java.util.Set, vc pode partir para composição + interface + delegação, que vc irá obter o mesmo resultado de herança. A única diferença, ao meu ver, é que vc vai ficar com muitas linhas a mais e repetitivas na sua classe, implementando novamente todos os métodos da interface e fazendo a delegação para o objeto possuído. Não entendo se há alguma vantagem de eliminar herança dessa maneira a não ser pela retórica de que herança não vai bem com testes unitários. Se houvesse o Joshua Bloch teria feito isso aqui http://java.sun.com/javase/6/docs/api/java/util/LinkedHashSet.html, mas ele preferiu herdar de HashSet, sem falar de AbstractSet e AbstractCollection.

Acho que se Object é uma classe concreta e não uma interface, onde todos os outros objetos obrigatoriamente herdam de Object, então ficar evitando herança quando há claramente uma relação de hierarquia é non-sense.

Mas isso não tem muito haver com o tema original que é por que testes unitários não são populares. Eu sinceramente não sei a resposta para isso, nem se a afirmação é 100% correta. Pelo menos aqui no GUJ vejo que é bastante popular.

saoj wrote:...

O link tá errado, arruma aí.

não importa quem wrote:
Acho que vc deve preferir composição ao invés de herança quando não há hierarquia, quando vc não vai precisar passar o filho como pai para sistemas legados ou outros métodos do seu sistema que esperam o pai e podem fazer uso de polimorfismo recebendo o filho.

Ponto para as 10 mil linhas !

This message was edited 1 time. Last update was at 03/06/2008 11:06:24

pinto wrote:

não importa quem wrote:
Acho que vc deve preferir composição ao invés de herança quando não há hierarquia, quando vc não vai precisar passar o filho como pai para sistemas legados ou outros métodos do seu sistema que esperam o pai e podem fazer uso de polimorfismo recebendo o filho.

Ponto para as 10 mil linhas !

Nesse caso vc não está obrigado a implementar todos os métodos do objeto possuído, pois vc não está implementando uma interface, apenas usando composição porque não há uma relação de hierarquia.

Qualidade não tem nada haver com quantitidade. Se vc tem uma classe com mil linhas e o código está bem feito, who cares? Pra isso que existe IDE e os shortcuts do teclado.

Agora se vc tem uma classe com 10 mil linhas repetitivas, fazendo delegação para os métodos de uma interface, então é tedioso, error-prone e feio. As pessoas reclamam de getters e setters, o que dirá disso. Código tb deve ser bonito, uma forma de arte e não uma ciência exata. Se não usemos o Maker (na versão 54.3)...

o problema não é herança, herança não é ruim, ruim é herança má utilizada ...
Herança apenas para reutilização de campos/métodos causa mais problemas do que resolve.

Exemplo:
Um cliente a algum tempo atraz tinha uma classe "Usuario" e uma classe "UsuarioDependente", a classe "UsuarioDependente" tinha apenas um campo a mais que "Usuario" que era o relacionamento com o pai.

Pensamento lógico (e errado deles), "UsuarioDependente" vai herdar de "Usuario", isto foi uma péssima utilização de herança, e é este tipo de utilização que faz com que as pessoas assumam por regra que "herança é má".

Por que foi errado fazer isto? Por que nem todos os métodos que esperavam um "Usuario" podiam receber um "UsuarioDependente" ...
Por exemplo, considerando que houvesse um método:
public void gerarFatura(Usuario usuario)
Este não podia receber um "UsuarioDependente" pois o dependente não recebia fatura, tudo era cobrado do "Usuario".
A solução para corrigir este problema se não me engano foi criar um "UsuarioBase" e extender as duas classes deste.
Por que um "UsuarioDependente" não é um "Usuario", pois usuário tem comportamentos que os dependentes não possuem, como por exemplo, pagar a conta

Herança quando usada nos casos "é um", não tem problema algum, mas estes são poucos casos na grande maior parte dos sistemas que eu ja vi até hoje.
Em qualquer situação diferente de "é um", usar herança é errado e vai te trazer problemas, então em todas estas situações, não use herança, use composição.
E se você perceber que não usou herança nenhuma vez (no seu modelo, herdar de Object ou outras classes padrão do java não conta para o que eu estou descrevendo), não esquenta a cabeça, é provavel que não existisse mesmo nenhum tipo de relacionamento "é um" no seu sistema, a maior parte deles não tem mesmo.
Mas se existir um "é um", use herança sem pensar duas vezes

PS.: este port não é resposta a um post especifico desta thread, mas a quase todos, tanto os que dizem use herança para tudo quanto os que dizem nunca use herança, ambas as posições estão erradas, orientação a objetos bem utilizada ajuda muito, o problema é que a maior parte dos programadores que conheci nas empresa que trabalhei até hoje ( a maior parte não quer dizer todos) não conseguiu entender direito a OO ainda, então usa errado e tem problemas por causa disto.

pcalcado wrote:O Leonardo falou que uma classe com 100 métodos é um design ruim é deve ser evitado em primeiro lugar quando comentava sobre algum argumento de que isso prejudicaria testabilidade. Você respondeu dizendo que sistemas legados podem ter 100 métodos. Eu respondi dizendo que istemas legados devem ser refatorados e/ou isolados.

Podemos dizer então que você concorda com o Leonardo?

Parcialmente. Eu estava questionando justamente um trecho do que ele escreveu.

Primeiro, porque você tem um ÚNICA classe com cem, CEM!, métodos? Isso é design ruim, e provavelmente você não está utilizando herança, nem composição, nem orientação a objetos. Provavelmente é comportamento pra ser quebrado em algumas outras classes.

E eu respondi basicamente que pode acontecer em sistemas onde é obrigatório o uso de algum tipo de framework mal projetado (seja legado ou não). E mesmo assim JPasswordField extends JTextField extends JTextComponent extends JComponent extends Container extends Component extends Object. Ou seja, há um uso grande de herança. Obviamente, há falhas de projeto nestas classes intermediárias (em especial Component, Container e JComponent, que são as principais culpadas por existir centenas de métodos). Essas três pode ser o caso onde não há nem herança, nem composição e nem OO (daí eu concordaria com ele), MAS quanto a JPasswordField, JTextField e JTextComponent, sem dúvida há um uso propício de herança. Basicamente, o problema é que você é obrigado a herdar esses métodos (mesmo se não os quiser), e EU não posso refatorar o swing para eliminar isso, ou seja, o framework ruim me forçou a herdar um caminhão de métodos.

No final crio a minha classe que herda de JPasswordField. EU estou usando a herança de forma propícia, MAS a minha classe tem centenas de métodos (porque estes foram herdados). E isto não é um design ruim que é minha culpa, e sim culpa do framework (no caso, neste exemplo, o swing e o AWT).

Quanto ao resto do post dele, não comentei nada.

urubatan wrote:...

Concordo quase completamente. O único ponto que discordo é em relação a "(no seu modelo, herdar de Object ou outras classes padrão do java não conta para o que eu estou descrevendo)". Já vi gente criando heranças absurdas como MinhaData extends java.util.Date.

O caso clássico de mal uso de herança é o infame java.sql.Date extends java.util.Date.

This message was edited 1 time. Last update was at 03/06/2008 12:32:57

pcalcado wrote:
3) Heranças atrapalham testes da mesma maneira que composição atrapalha: quando se cria acomplamento com classes difíceis de serem testadas. O resto escrito neste tópico é FUD

Shoes nao entendi muito bem prq herança atrapalharia em testes por qual motivo?
No livro design Patterns (Head First) eles recomendam que de prioridade a composição em relação a heranca depois que li o captiulo abriu a minha mente em utilizar Herança

saoj wrote:

pinto wrote:

...

O objetivo (admito que não ficou claro...) do meu comentário foi comparar a grande complexidade da OO com a "extensa" simplicidade da programação estruturada (que foi a minha escola na TI). Por isso a comparação entre o seu parágrafo e as 10 mil linhas.
Aplicar corretamente a OO é tão difícil quanto formar um consenso sobre o que é correto se fazer em OO.
Realmente OO não é pra qualquer um...

saoj wrote:
Código tb deve ser bonito, uma forma de arte e não uma ciência exata.

Seria bom se mais gente pensasse assim.

saoj wrote:
Se não usemos o Maker (na versão 54.3)...

Boa...

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