Classe Abstrata ou Interface

JavaBaby Membro desde: 25/07/2008 22:43:59 Mensagens: 84 Offline

Paulo Silveira wrote:
Intefaces com muitos metodos, como disse o thingol, é sinal de design ruim. Mesmo ocorre com Connection e alguns listeners.

Ow, no livro use a cabeca padroesde projetos, o autor fala muito sobre composição, no padrão strategy é q mais fala sobre isso.
pelo q entendi, strategy usa composição.
A pergunta é:
"qndo eu utilizo a composição estou usando o padrao strategy"?
falow

Não necessáriamente!

Crie um novo tópico para discutir isso!

JavaBaby Membro desde: 03/01/2008 09:08:40 Mensagens: 84 Offline

Paulo Silveira wrote:prefira sempre o uso de interfaces (e da para sempre usar interfaces em vez de classe abstrata, se voce gastar um pouquinho mais de codigo e fizer composicao). é mais elegante, mais flexivel e menos acoplado... justo porque nao ha heranca de codigo. algumas pessoas consideram heranca uma forte quebra de encapsulamento.

Pode mostrar um exemplo pratico de uso de interfaces + composição e outro com classe abstratas ? Acho que fica melhor explicado.

Abraços

Estou ressucitando este tópico para discutir um caso especial:

Paulo Silveira wrote:Pra ser sincero, nao vejo nenhum caso. Hoje sou bem xiita que nem o James Gosling, Erich Gamma e Joshua Bloch, que descem a lenha em cima de heranca!

Paulo, neste link o autor expõe um exemplo onde a herança seria adequada:

E justifica com o texto abaixo ( traçando um paralelo entre as 5 regras que regem o uso de herança ):

- Regra 1 (tipo especial): ok. Uma Reserva é um tipo especial de Transação e não um papel assumido por uma Transação
- Regra 2 (mutação): ok. Uma reserva sempre será uma Reserva, e nunca se transforma em Compra (se houver uma compra da passagem, será outra transação). Idem para Compra: sempre será uma Compra
- Regra 3 (só estende): ok. Ambas as subclasses estendem Transação com novas variáveis e métodos e não fazem override ou anulam coisas de Transação
- Regra 4 (não estende classe utilitária): ok.
- Regra 5 (tipo especial de papel/transação/dispositivo): ok. São tipos especiais de Transação

Você concorda com a análise dele? Se discordar, em quais pontos? Na sua opinião, seria coerente forçar a composição afirmando que uma Transacao tem um tipo, e não é de um tipo?

Abraços

P.S. - direcionei a questão ao Paulo por causa de sua afirmação citada no início do post, mas gostaria de saber a opinião da galera do fórum também.

Só dando um up...

Eu acho meio hipócrita do Gosling ou qualquer outro envolvido com a criação de Java falar mal de herança. O grande problema é que Java não oferece nenhum mecanismo para reuso de código comparável a herança. Se houvessem mixins ao menos...

tnaires wrote:
class Transacao { } class Reserva extends Transacao { } class Compra extends Transacao { }

Não dá para dizer. Sem conhecer o domínio e a implementação qualquer exemplo é falho. O que é uma Transação neste contexto? Eu já trabalhei para alguns bancos e cada um tem um conceito diferente, mesmo várias definições dentro da mesma instituição.

Eu não sou xiita quanto a isso simplesmente porque já vi muita besteira sendo feita em nome de "herança é ruim, use composição". Isso é uma rule of thumb e não uma lei. Como falei antes o design de Java faz com que seja muito difícil resolvermos problemas comuns sem heranças ou gambiarras (strategy de uma implementação só e o fim).

Para mim, a decisão entre delegação e herança passa pelo domínio e este é o principal juiz. Esta delegação faz sentido no domínio? Eu dificilmente criaria uma classe extra na Camada de Negócios só para satisfazer uma rule of thumb.

Ps: Tarso, dar up é muito feio.

This message was edited 2 times. Last update was at 12/10/2008 11:03:34

pcalcado wrote:Ps: Tarso, dar up é muito feio.

Desculpe

... Você acreditaria se eu dissesse que pensei mil vezes antes de fazer isso? Fiz porque a rotatividade do Java Básico é muito alta, e também porque não encontrei outra opção de torná-lo visível novamente.

pcalcado wrote:Não dá para dizer. Sem conhecer o domínio e a implementação qualquer exemplo é falho. O que é uma Transação neste contexto? Eu já trabalhei para alguns bancos e cada um tem um conceito diferente, mesmo várias definições dentro da mesma instituição.

Entendo. Aparentemente trata-se de uma transação financeira e não bancária. O contexto no qual o exemplo se encaixa é muito vago, não dá mais detalhes sobre o domínio.

pcalcado wrote:Eu não sou xiita quanto a isso simplesmente porque já vi muita besteira sendo feita em nome de "herança é ruim, use composição". Isso é uma rule of thumb e não uma lei.

Pois é... Eu estava falando justamente isso pra um amigo meu que leu sobre isso há pouquíssimo tempo, e ficou xiita quanto à herança. Quando algumas pessoas se deparam com esse "mantra" pela primeira vez, ficam tão impressionadas que passam a abominar totalmente seu uso. Isso ocorre porque elas vinham utilizando herança em todas as situações que requeriam apenas composição ( o caso Pessoa -> PessoaFisica é clássico ).

Zakim wrote:Poderiam citar algum caso em que a herança valha a pena em relação a composição?

para implementações como nas classes de stream no pacote java.io, utilizando a concepção do pattern decorator.

netShot wrote:Pode mostrar um exemplo pratico de uso de interfaces + composição e outro com classe abstratas ? Acho que fica melhor explicado

um exemplo de composição a partir de interfaces você pode visualizar a partir deste modelo abaixo pelo padrão observer:

já para um modelo com classes abstratas, seria o mesmo padrão utilizando as classes no pacote java.util, como Observable. neste caso prefiro o 1º caso.

faelcavalcanti wrote:um exemplo de composição a partir de interfaces você pode visualizar a partir deste modelo abaixo pelo padrão observer:

Outro exemplo é o padrão Strategy:

http://en.wikipedia.org/wiki/Strategy_pattern

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