[Cascavel-pm] Com que Class::* eu vou

Igor Sutton Lopes igor.sutton em gmail.com
Quinta Março 29 15:20:15 PDT 2007


Olá Solli,

On 2007/03/29, at 22:55, Solli Honorio wrote:

> Pessoal,
>
> A minha preguiça e, principalmente, a falta de tempo, faz com que  
> eu abuse do conhecimento de vocês para me ajudar a escolher uma  
> classe que me ajude no POO.
>
> Me simpatisei com o Class::Std apresentado no Perl Best Pratice,  
> mas parece que alguém já desaconselhou este módulo.
>
> E aí, qual a experiência de vocês com o POO e qual(is) módulo(s)  
> vocês recomenda(m).

Como andamos discutindo antes sobre engenharia de software, eu acho  
que você deve procurar o que é importante para o projeto que estás  
fazendo e achar a ferramenta certa -e acabar com aquela impressão de  
que se você tem um martelo, o resto tudo é prego.

Em relação à programação orientada a objetos em Perl, eu tenho visto  
várias pessoas utilizarem objetos quando não são necessários. Um caso  
típico disso é encapsular funções em um objeto que por definição não  
é stateless nem statefull. Nestes casos, o aconselhável seria  
utilizar um pacote e exportar as funções necessárias no load do  
pacote, ex:

     use My::Package qw(my_func);

Isto é explícito, não enche o namespace main de tralhas e quando você  
olhar o seu código seis meses depois vai saber de onde vem my_func  
sem muito esforço.

Um exemplo de má utilização de Orientação à Objetos seria por exemplo:

</code>
package My::Class;

sub new {
     my ($class) = @_;
     my $self = {};
     bless $self, $class;
     return $self;
}

sub my_func {
     my ($self, $param) = @_;
     return int($param) * 2;
}
</code>

Se você prestar atenção, verá que My::Class::my_func() não utiliza  
nenhuma informação sobre o objeto, então... Prá que precisamos de  
objeto?

Então... Depois de analisar o seu problema, e você chegar à conclusão  
que orientação à objetos é o que você precisa, você pode ter uma  
abordagem simplista, utilizando a técnica padrão de OO do Perl -vide  
método new() acima- e também mais aberta e flexível, isto é, você  
fornece a API para o consumidor do seu código e ele deve utilizar  
*porém* não é estrito e todos os seus dados são carregados junto com  
a referência do objeto -seja ele um hash, array ou scalar- ou a  
técnica de objetos InsideOut, que sua maior característica é manter  
os atributos da classe armazenados em uma estrutura de dados com  
escopo léxico do pacote.

Para maiores detalhes sobre isto, aconselho a leitura da coluna[1] do  
Randal sobre o assunto.

Eu ainda não passei para o lado dos adeptos de objetos inside-out,  
apesar de eu achar bastante interessante. Acredito que se existam  
APIs, devemos utilizá-las e, caso não as utilizemos, paguemos o preço  
disso :-)

Boa sorte!

[1] http://www.stonehenge.com/merlyn/UnixReview/col63.html

--
Igor Sutton
igor.sutton em gmail.com



-------------- Próxima Parte ----------
Um anexo não texto foi limpo...
Nome  : PGP.sig
Tipo  : application/pgp-signature
Tam   : 186 bytes
Descr.: This is a digitally signed message part
Url   : http://mail.pm.org/pipermail/cascavel-pm/attachments/20070329/53df7ca1/attachment.bin 


Mais detalhes sobre a lista de discussão Cascavel-pm