|
Nem tanto ao c�u, nem tanto ao
inferno... "Programe para uma
interface, n�o para uma implementa��o" (do livro
Design Patterns: Elements of Reusable Object-Oriented Software Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides) At� onde isso � verdade? Na
minha opini�o, quase sempre. Esse quase significa que, se
eu vou construir uma ou duas, quem sabe cinco classes n�o muito grandes, para
implementar uma funcionalidade razoavelmente simples, pra que interfaces? A
utiliza��o de interfaces pressup�e requisitos para tal, quando, por exemplo, eu
tenho um processo baseado em OO, onde os participantes pensam orientado a
objeto, os conceitos s�o, na medida do poss�vel, naturais para os envolvidos, e
acima de tudo, os requisitos ser�o melhor atendidos. Por outro lado, boto minha m�o
no fogo pela constru��o de interfaces. Os projetos hoje (e desde sempre), se
tornam cada vez mais complexos, as equipes cada vez maiores, os requisitos cada
vez em maior n�mero. � necess�rio que todos falem a mesma l�ngua. Padroniza��o.
N�o para engessar o processo, mas para derrubar a torre de Babel. Respondendo seu
questionamento, a meu ver, n�o se trata de uma tradi��o de programadores
simplistas. At� porque eles tem prazos, e isso est� acima de qualquer
tecnologia. Se precisa entregar o sistema, o cara diz "que interface coisa
nenhuma, eu vou � botar pra funcionar!!". A quest�o � que, apesar de ter
mais de 40 anos de estrada, a orienta��o a objeto ainda n�o faz parte da
cultura comum desenvolvedores de sistemas (aqui incluo todos os envolvidos). A Orienta��o a Objeto, como
toda ferramenta poderosa, tamb�m � muito perigosa. Precisa ser manuseada com
cuidado, sen�o s� atrapalha. Melhor dar uma pausa, sen�o eu
me empolgo... Abra�os, Denard -----Original Message----- PessoALL, Ontem eu estava discutindo com um amigo, que est� come�ando a
desenvolver em C++. Ele me perguntou sobre heran�a m�ltipla em Java. (Estamos falando
de conceitos, ok?). Ai eu coloquei para da seguinte forma (Exemplo Cl�ssico): "Suponha que vc tenha um carro e um barco. Se vc quer um
carro-anf�bio, basta que vc crie uma classe filha de ambas. Por�m, sabemos que isso � conceitualmente errado. Para obter um carro anf�bio,� n�o
nos basta juntar o conceito de carro com o conceito de navio.� Na verdade,
temos uma lista de requisitos para que classifiquemos algo como barco, e uma segunda para que classifiquemos
algo como carro. Para criarmos um carro-anf�bio portanto, devemos criar algo que (a�
sim) preencha uma nova lista de pr�-requisitos, formada pela uni�o das duas anteriores. Da� sim, poderemos criar um
"molde"(Classe/Implememta��o) de carro anf�bio, e permitir sua produ��o em massa
(Inst�ncias/Objetos)." Ai vem minha pergunta, depois de contar essa hist�rinha, que eu
refleti... Ser� que as pessoas n�o est�o acostumadas a programar de maneira muito simplista? Eu digo isso com base no descaso que as pessoas fazem do uso de
interfaces. A eu ver , a programa��o processual (macro-programa��o) deve ser feita apenas a n�vel de interface, e as particulariza��es de um sistema, a�
sim, implementadas em classes. Obviamente no final devemos implementar uma
classe para fazer o papel de cada interface, mas ela s� preencher� (micro-programa��o) o esqueleto criado com as interfaces. Que vc's acham disso, na teoria e pr�tica? Vc's trabalhado assim? Em suma, vamos discutir o assunto? ��� []'s a todos ������� P.O. ps-> Desculpem� email longo. ------------------------------ LISTA SOUJAVA
---------------------------- http://www.soujava.org.br� -� Sociedade de Usu�rios Java da Sucesu-SP d�vidas mais comuns: http://www.soujava.org.br/faq.htm regras da lista: http://www.soujava.org.br/regras.htm para sair da lista: envie email para
[EMAIL PROTECTED] ------------------------------------------------------------------------- |
- [java-list] RE:_[java-list]_Heran?a_Multipla_-_enfim_uma_... Denard . Soares
- [java-list] RE:_[java-list]_Heran?a_Multipla_-_enfim... Ricardo Santiago
