|
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
