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

[Daniel Ruoso]

Em Qui, 2004-06-17 às 14:30, Luis Campos de Carvalho escreveu:
>    Bom, para os que não sabem, eu me considero radical xiita no tangente 
> à filosofia OO.

Hmmmm... sou por um lado, mas discordo de outros...

>    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.

Essa é a solução adotada pelo Swing do Java, é elegante, sem dúvida, mas
para o uso do dia-a-dia, toda a estrutura se torna complexa de um jeito
que é muito trabalhoso fazer as coisas normais (acredite, estou
trabalhando com swing a um ano e meio e EU ODEIO).

A questão é, eu prefiro deixar mais simples para o uso regular e só
complexificar nos casos específicos, permite que a infra-estrutura seja
simples...

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

Sim e não, por causa da complexidade que causa. Fazer escolhas em
momentos da implementação simplifica muito, e a alteração dinâmica
permite que altere essas escolhas em casos específicos.

>    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)

É nessa parte que eu não sou xiita... pra mim OO e perl é o casamento
perfeito, porque você tem as vantagens do OO com a simplicidade do perl,
você escreve muito menos código, reaproveita muito mais e ainda não tem
que ficar brigando com a linguagem por que ela não deixa isso ou
aquilo... :)

> > 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.

A diferença é que eu não mecho na tabela de herança, por que eu só quero
mudar um método... é como se aquele método sempre tivesse sido daquele
jeito.

>    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á?).

O desenvolvedor, ele sabe o que está fazendo...

Abraços