Command Pattern (estendendo o Casual Class...)

Depende muito da situacao. Fazer Command ser uma classe abstrata significa que voce nao podera estender nenhuma outra classe. Usando interfaces, esse problema nao ocorre.
Salvo um motivo muito especial, nao ha razao para fazer de Command uma classe abstrata se a implementacao normal somente tem um metodo “execute()”.

Rafael

“Rafael Steil”:

Depende muito da situacao. Fazer Command ser uma classe abstrata significa que voce nao podera estender nenhuma outra classe. Usando interfaces, esse problema nao ocorre.

Olá Rafael

Bom, na verdade, a unica diferença que realmente achei interessante é que, ao usar classes, pode facilitar a adicao de funcionalidades no Command, pois automaticamente as subclasses herdarao as propriedades e comportamentos, podendo significar um numero reduzido de alteracoes. É claro que para isso a SuperClasse Command não deverá ser abstrata (se vc ver o Action, do struts, ela não é abstrata).

Contornar a limitação a heranca multipla de classes simplesmente com o uso de interfaces eu nem sempre acho uma boa solução. Depende muito da situação… Ja q o proposito deles, na verdade, sao bem distintos… e pensado em fases diferentes de um projeto. (interface antes, e classes depois, mais durante a implementacao).

Bom, se vc estiver se referindo às classes adaptadoras, aí concordo!

Gerson K.

Muitos frameworks usam o Command Pattern (webwork, struts, prevayler, OSWorkflow… a lista eh grande… :), e em todos eles da pra notar que os comandos devem implementar uma interface (Action, Command, qualquer que seja o nome dela), mas geralmente os frameworks já dão uma canja com uma classe quebra-galho que vc estende (ActionSupport, AbstractCommand), e por aih vai. Acho uma boa ideia, e simplifica bem o desenvolvimento… que tal?

[]'s
-cv

Todos não. Pelo menos no Struts, que eu já vi, o Action é uma interface.
Dá pra fazer tanto por interface ou classes (abstrata ou não)

Gerson K.