[Cascavel-pm] O código mais bizonho q ue eu já fiz na minha vida (v. 2 .0)

[Luis Campos de Carvalho]

Flavio S. Glock wrote:
> Luis, você tem razão sobre isso. 
> 
> O que eu queria saber é o que você acharia de ter um módulo 
> Classe::B::Plugin que altera o funcionamento da Classe::B -
> Esta não é uma solução meio "suja" do ponto de vista de OO ?

   Bom, para os que não sabem, eu me considero radical xiita no tangente 
à filosofia OO.

   Não considero "suja" a solução de ter plugins. Ela não altera o 
funcionamento da Classe::B. A Classe::B continua obedencendo exatamente 
ao mesmo padrão de projeto estabelecido inicialmente. Ela é um 
"Dispatcher" (alguém bom de padrões me corrija o nome desta coisa, por 
favor), que simplesmente delega o comportamento a uma implementação 
específica. No exemplo, para Classe::B::Plugin.

   Vejamos: Classe::B não precisa saber o que Classe::B::Plugin faz, ou 
como responde às mensagens passadas -- Encapsulamento: OK; Classe::B não 
se incomoda com a troca de Classe::B::Plugin para Classe::C::Plugin, ou 
qualquer outro objeto que respeite a interface estabelecida -- 
Polimorfismo: OK; Classe::B não se importa em falar com um descendente 
de Classe::B::Plugin: Herança OK.

   Me parece uma solução filosoficamente muito mais interessante do que 
permitir a um objeto (ou classe) alterar dinamicamente um outro objeto.

> Por exemplo, como você faria para acrescentar código a 
> um método já existente na Classe::B ? Quando você 
> redefine um método, a versão anterior é perdida (você tem
> que reescrever tudo de novo), e ainda por cima você ganha uns warnings.

   Claro, isso depende muito do que o método original faz. Vamos usar 
seu exemplo de hierarquia anterior, e vamos tentar fazer de acordo com a 
filosofia OO:
   Para reescrever um método, você pode acrescentar uma chamada para 
__SUPER__->method(), e ter certeza de que o método original é chamado 
(antes ou depois de você realizar seu procedimento extra).

   Caso você precise alterar o comportamento, eu tenho certeza de que o 
correto é __mesmo__ reescrever o método. Isso quer dizer que o problema 
é com a concepção filosófica do OO ser incompatível com a concepção 
filosófica do Perl (lazyness, rubishness, impatience)

> Me parece que tanto o programa do Daniel Ruoso, como o
> Class::ClassDecorator
> tentam resolver este problema de como modificar uma herança que já 
> foi estabelecida.
> 

   E eu não disse que não são boas tentativas. Eu disse que eu as 
considero tentativas perigosas, por violarem o encapsulamento (quem 
garante que o método que você deseja alterar está mesmo lá?).

   Estou achando isso interessante...
   Putamplexos!
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
   Luis Campos de Carvalho is BSc in Comp Science,
   PerlMonk [SiteDocClan], Cascavel-pm Moderator,
   Unix Sys Admin && Certified Oracle DBA
   http://br.geocities.com/monsieur_champs/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=