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

Eden Cardim edencardim em gmail.com
Sexta Março 30 11:15:52 PDT 2007


On 3/29/07, Igor Sutton Lopes <igor.sutton em gmail.com> wrote:
> 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.

Concordo, mas vale lembrar que manutenibilidade é importante para
quase qualquer projeto, e a proposta principal do paradigma OO é de
atender esse requisito. Eu tendo a sempre usar OO, porque tem muito
"hype" associado então é bem fácil conseguir suporte gratuito quando
eu precisar.

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

Sei o que você quer dizer, isso também está associado ao fato do OO
ser bem disseminado, mas pouco entendido. Já vi vários programadores
Java (e de outras linguagens também, mas focalizo nos do Java porque
gostam de se gabar de serem os "fodões" do OO) escreverem código
declarando uma única classe onde todos os atributos e métodos eram
públicos, dizendo que isso é OO.

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

Hmm, acho que isto está sujeito a debate. Código também é informação,
apesar de ser executável. Alguém poderia criar uma classe e instanciar
um objeto sem usar informação sobre o objeto, para implementar, por
exemplo, os padrões de projeto Template Method e Strategy. Esses dois
padrões caem nesse caso que você falou, porém o uso deles favorece
bastante a extensibilidade do código.

> a referência do objeto -seja ele um hash, array ou scalar-

...ou CODE ou GLOB.

-- 
Eden Cardim
Instituto Baiano de Biotecnologia
Núcleo de Biologia Computacional e Gestão de Informações Biotecnológicas
Laboratório de Bioinformática
--
"you seem to think that 'close enough' is close enough...
please learn to be 'literal' around programming."
merlyn - on irc.freenode.net#perl


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