Métodos mágicos

[André Marcondes 3]

Ola.

 

Recentemente, eu li em um artigo do imasters (

http://imasters.com.br/artigo/21215/php/a-nova-era-de-frameworks-php

) que usar os métodos mágicos na orientação a objetos com php não é recomendável, porque eles deixam o código obscuro.

Sinceramente, não entendi o que o autor queria dizer com isso.

Alguém pode me explicar qual o problema em usá-lo e o que eu poderia usar para substituir sua funcionalidade?

 

Obrigado.

[Vinicius Rangel 208]

vai de opinião muita gente ainda prefere usar os métodos mágicos mais na minha humilde opinião que não gosto de trabalhar então não me aprofundei muito é que esses métodos demoram para carregar e fazer o que tem que ser feito por utilizar muito recursos o que não acontece em uma estrutura que não se usa esses métodos sendo que essa estrutura foi escrita de maneira correta seguindo varias regras e com um padrão para programar

[André Marcondes 3]

como é? não entendi nada.

[Vinicius Rangel 208]

Os métodos mágicos podem deixar lento sua aplicação pois trabalham com muitos recursos do PHP o que exige mais do servidor.

[Gabriel Heming 766]

os únicos métodos mágicos que eu utilizo são:

 

__construct

__destruct

__toString

__clone

 

Na minha opnião, métodos mágicos como __set e __get, quando utilizados para o desenvolvimento de uma classe, faz com que, o desenvolvedor, que não desenvolveu a classe mas irá utilizá-la, precisa ser "mágico" para descobrir os atributos que uma classe possui.

[visitante_php 0]

os únicos métodos mágicos que eu utilizo são:

 

__construct

__destruct

__toString

__clone

 

Na minha opnião, métodos mágicos como __set e __get, quando utilizados, o desenvolvedor precisa ser "mágico" para descobrir os atributos que uma classe possui.

 

simplesmente pq o mesmo nao documentou a classe neh, muitos nao o fazem e se perdem..eu ja fui um deles, hj documento tudo, desde uml at phpdoc...na minha opiniao os metodos magicos eh o q deixa o php dinamico, mais flexivel, pois muitas linguagem esbarram ora na tipagem ora no dinamismo...

[André Marcondes 3]

Alguém poderia me dar um exemplo?

Para mim, os métodos mágicos são algo bom, não entendo qual o problema.

[Gabriel Heming 766]

simplesmente pq o mesmo nao documentou a classe neh, muitos nao o fazem e se perdem[...]

 

Exatamente!!!

Talvez por eu ter aprendido OO no java, eu seja meio cético quanto essa flexibilidade do PHP.

 

Eu vejo a flexibilidade como uma brecha para despadronizações ( assim como aconteceu ao HTML. Depois foi criado o XHTML para resolver isso ).

 

Por isso gosto da inflexibilidade que o Java tem, e tudo que construo em PHP, me baseio em Java.

 

E também deixo uma citação do João Batista Neto do seu artigo PHPog: uma questão de design?

 

[...]Se você não ler o código, você não vai saber que esse objeto pode voar, ou seja, esses ditos métodos mágicos não são realmente mágicos, na verdade são feitos para que programadores que possuem poderes mágicos ou uma bola de cristal possam utilizar.[...]

[visitante_php 0]

Eu vejo a flexibilidade como uma brecha para despadronizações ( assim como aconteceu ao HTML. Depois foi criado o XHTML para resolver isso ).

se fosse assim, os contorcionistas ficariam com seus corpos deformados...

muitos fazem

 

$id = $_GET['id'];

 

mas seuqer fazem devida validacao...nao eh regra, mas eh deixar brecha de seguranca, assim como tb ocorre em java,

 

public Integer i = "test";

 

o java tb vai chiar, por conta da nao validacao...

 

tudo depende do programador...tudo...

 

 

Por isso gosto da inflexibilidade que o Java tem, e tudo que construo em PHP, me baseio em Java.

cada linguagem tem suas facilidades e dificuldades, por isso nao deveria se basear numa linguagem pra escrever outra, se fosse assim, eu faria

 

int $var;

 

no php, nao sao a mesma coisa...

 

E também deixo uma citação do João Batista Neto do seu artigo PHPog: uma questão de design?

 

[...]Se você não ler o código, você não vai saber que esse objeto pode voar, ou seja, esses ditos métodos mágicos não são realmente mágicos, na verdade são feitos para que programadores que possuem poderes mágicos ou uma bola de cristal possam utilizar.[...]

Joao eh admiravel, porem você deveria se basear em suas experiencias, e nao nas dos outros, ker q alguem viva sua vida por você?

[Gabriel Heming 766]

porem você deveria se basear em suas experiencias, e nao nas dos outros, ker q alguem viva sua vida por você?

Quando eu estudei as normas da ABNT artigos/trabalhos científicos. Citação era uma forma de utilizar a opinião de outra pessoa em prol do que eu estou defendendo. Acredito que ainda não tenha mudado (ainda, mudaram até a trema '-'). Então, só utilizei o que ele falou em prol da minha opinião sobre métodos mágicos. E sobre minha experiência em PHP:

- 9 entre 10 programadores, com que eu trabalhei, não documentam.

- todos os programadores, com que eu trabalhei, que utilizam métodos mágicos, não documentam.

 

[...]por isso nao deveria se basear numa linguagem pra escrever outra, se fosse assim, eu faria

 

int $var;

 

no php, nao sao a mesma coisa...[...]

bem que eu gostaria de poder escrever tudo no PHP como se escreve em Java.

 

Mas por exemplo.

 

Se eu for escrever um método como este:

public function setInt( int $int ) {
  ...
}

 

Na hora que eu for chamá-lo, o PHP dirá que eu estou passando um Integer quando o esperado era um int.

 

se eu for mudar para:

 

public function setInt( Integer $int ) {
  ...
}

 

O PHP irá emitir o mesmo erro, só que dessa vez, dirá que eu estou passando um Integer quando o esperado era um Integer (WTF???????)

 

Sim, eu já testei.... gostaria que o type hinting do PHP fosse tão bom quanto do Java. Eu posso viver com isso, não disse que não.

 

Utilizando um exemplo bem chulo: É como pegar alguém que fez a cirurgia de mudança de sexo, o "resultado" é o mesmo. Mas, lá no fundo, é diferente e eu não gosto dessa diferença. '-'

 

Voltando ao PHP, eu posso "viver" com as diferenças, só não gostaria de muitas delas.

[André Marcondes 3]

Eu estou lendo um livro do Pablo Dall'Oglio chamado "PHP - Programando com Orientação a Objetos".

Neste livro ele apresenta os métodos mágicos __set, __get e __call.

 

A funcionalidade oferecida por estes métodos é bem interessante, mas como dizem que não é recomendável, existe alguma solução orientada a objetos para implementar sua funcionalidade? (ressalto que li o artigo "PHPog: uma questão de design?" de João Batista Neto, citado pelo Gabriel, mas o que ele apresenta não é exatamente uma solução a estes métodos mágicos especificamente falando.

[visitante_php 0]

@gabriel, pois eh, muitos programdores php nao documentam, a maioria pq aprendem php em tutoriais q nao estimula a documentar, o oposto do java, se ver aki no forum, muitos sequer usam a busca, postam a mesma duvida varias vezes (os imaturos e preguiçosos ainda t dao '-1' se você postar um link q o ajuda)

 

o type hinting varia de IDE pra IDE

 

o php eh dinamico, muitas coisas q atrapalham, dificultam e delongam...o compilador do php foi feito pra interpretar e converter ele mesmo, por exemplo você pode converter uma string pra int ou vice-versa em php, em java nao eh possivel, você tem q fazer na mao...

[André Marcondes 3]

Ainda não responderam minha pergunta.

Será que podem colocar alguns exemplos?

[Gabriel Heming 766]

@Igor.php

Não digo que o PHP não possui seu méritos.

Além do que você já citou, o PHP também possui array dinâmicos (Java somente com ArrayList ou Vector), programação procedural (Java somente OO), uma vasta quantidade de bibliotecas que poucos programadores conhecem (a SPL por exemplo) e muitos outros benefícios sobre qualquer linguagem de programação. Todas as linguagens tem seus méritos, só tenho o direito de não concordar com alguns ou muitos deles. E esse tipo de discussão (do tipo abordagem de assunto e não ofensivo), como a nossa, é importante para ver diferentes pontos de um mesmo "problema/solução".

 

Bom, para não perder o foco no assunto, como falei anteriormente, acho métodos mágicos são ruins para uma "boa" programação. Entretanto, eles facilitam o desenvolvimento e acrescentam uma flexibilidade a linguagem. Vai de cada um utilizar ou não. Só o fato de você utilizar __set ou __get, te poupa um bom tempo criando setteres e getteres...

__call e __callStatic, facilitam na hora do overload de métodos, já que o overload do php é bem precário. Mas vai de cada desenvolvedor mesmo.

[visitante_php 0]

@Igor.php

Não digo que o PHP não possui seu méritos.

Além do que você já citou, o PHP também possui array dinâmicos (Java somente com ArrayList ou Vector), programação procedural (Java somente OO), uma vasta quantidade de bibliotecas que poucos programadores conhecem (a SPL por exemplo) e muitos outros benefícios sobre qualquer linguagem de programação. Todas as linguagens tem seus méritos, só tenho o direito de não concordar com alguns ou muitos deles. E esse tipo de discussão (do tipo abordagem de assunto e não ofensivo), como a nossa, é importante para ver diferentes pontos de um mesmo "problema/solução".

 

Bom, para não perder o foco no assunto, como falei anteriormente, acho métodos mágicos são ruins para uma "boa" programação. Entretanto, eles facilitam o desenvolvimento e acrescentam uma flexibilidade a linguagem. Vai de cada um utilizar ou não. Só o fato de você utilizar __set ou __get, te poupa um bom tempo criando setteres e getteres...

__call e __callStatic, facilitam na hora do overload de métodos, já que o overload do php é bem precário. Mas vai de cada desenvolvedor mesmo.

entao você chegou onde eu keria chegar

 

@andre

(ressalto que li o artigo "PHPog: uma questão de design?" de João Batista Neto, citado pelo Gabriel, mas o que ele apresenta não é exatamente uma solução a estes métodos mágicos especificamente falando. )

 

concordo

 

 

muitos aki falam de problemas, mas solucoes nao aparecem...

[Gabriel Heming 766]

Um pequeno exemplo, peguei alguns dos métodos mágicos que eu acho os mais utilizados (não documentei por falta de tempo e na função clone,do modo que eu implementei, o correto seria emitir um Error e não um Notice, para parar a execução do script):

 

classe Classe

class Classe {

   /** atributos **/
   private $data = array();


   /** métodos mágicos **/
   public function __construct() {
       echo 'construtor<br/>';
   }

   public function __destruct() {
       echo 'destrutor<br/>';
   }

   public function __call( $nomeMetodo, $argumentos) {
       printf( "Chamando metodo '%s'. Argumentos: %s<br/>", $nomeMetodo, implode(', ', $argumentos) );
   }

   public static function __callStatic($nomeMetodo, $argumentos) {
       printf( "Chamando metodo estático '%s'. Argumentos: %s<br/>", $nomeMetodo, implode(', ', $argumentos) );
   }

   public function __clone() {
       trigger_error('Não é permitido clonar a classe.', E_USER_NOTICE);
   }

   public function __get( $nomeAtributo ) {
       return $this->data[$nomeAtributo];
   }
   public function __set( $nomeAtributo, $valorAtributo ) {
       $this->data[$nomeAtributo] = $valorAtributo;
   }

   public function __toString() {
       $string = '
           Classe de nome Classe <br/> 
           Possui os seguintes atributos <br />';
       foreach( $this->data AS $key => $valor ) {
           $string .= sprintf( 'Atributo: %s -> Valor: %s <br/>', $key, $valor );
       }

       return $string;
   }
}

 

Utilizando:

$classe = new Classe();
$classe->nome = 'Gabriel';
$classe->sobrenome = 'Heming';
$classe->funcao = 'Desenvolvedor';
$classe->voa();
Classe::voa();
$classe2 = clone $classe;
echo $classe;

 

Saída esperada:

construtor

Chamando metodo 'voa'. Argumentos:

Chamando metodo estático 'voa'. Argumentos:

 

( ! ) Notice: Não é permitido clonar a classe. in C:\wamp\www\teste.php on line 27

 

Classe de nome Classe

Possui os seguintes atributos

Atributo: nome -> Valor: Gabriel

Atributo: sobrenome -> Valor: Heming

Atributo: funcao -> Valor: Desenvolvedor

destrutor

 

Esse é apenas um pequeno exemplo, existem muitas coisas que podem ser feitas com os métodos mágicos, seria algo como "deixa a imaginação rolar". Esse é o meu medo '-'

[hinom 5]

#1

deixam o código obscuro.

Sinceramente, não entendi o que o autor queria dizer com isso.

:seta:

#9

na verdade são feitos para que programadores que possuem poderes mágicos ou uma bola de cristal possam utilizar

[Bruno Augusto 417]

Discordo que método mágicos obscurecem o código.

 

A obscuridade se instaura quando há indisciplina no uso de tais métodos, resolvendo QUALQUER problema com métodos mágicos.

 

Poxa, __set(), __get(), __isset() e __unset() são os componentes básicos que permitem à uma View Engine proporcionar simplicidade e, até mesmo, mais elegância no código.

 

Pra mim é muito mais preferível setar nos Controllers:

 

$this -> view -> name = 'Bruno Augusto';

E no Template, invocar:

 

<?php echo $this -> name; ?>

Ao invés de:

 

$this -> view -> assign( 'name', 'Bruno Augusto' );

E no Template, invcar:

 

<?php echo $this -> getVar( 'name' ); ?>

E o __toString() então.

 

É muito útil para depurações, identificação de Objetos em uma Coleção (por nome), visualização de um SQL montado com base no Query Object sem a necessidade de um getter e muito mais.

 

__sleep(), __wakeup() e __clone não posso dizer muita coisa porque ainda não os uso/usei.

 

Mas o maior vilão da história é __call(). A funcionalidade oferecida por ele, se bem planejada, pode permitir que uma ponte seja criada entre diferentes classes.

 

Mas o uso irracional desse método acaba até mesmo por forçar uma herança múltipla entre classes o que não é de todo errado (olha as Traits do PHP 5.4 aí), mas se você precisa MESMO de herança múltipla, precisa, primeiro, rever seus conceitos de Orientação a Objetos.

[visitante_php 0]

Falou e disse, concordo plenamente...

[Gabriel Heming 766]

Já estava triste achando que o tópico iria acabar, e fico feliz por todo o conhecimento que pode-se agregar com esse tópico.

 

A obscuridade se instaura quando há indisciplina no uso de tais métodos, resolvendo QUALQUER problema com métodos mágicos.

Concordo plenamente. E essa indisciplina vem daqueles que eu mencionei, por experiência, que utilizam os métodos mágicos. Então, boa parte da minha opinião, e de qualquer um, vem das experiências, e a minhas não foram lá das muito boas.

 

 

Poxa, __set(), __get(), __isset() e __unset() são os componentes básicos que permitem à uma View Engine proporcionar simplicidade e, até mesmo, mais elegância no código.

 

Pra mim é muito mais preferível setar nos Controllers:

 

$this -> view -> name = 'Bruno Augusto';

E no Template, invocar:

 

<?php echo $this -> name; ?>

Ao invés de:

 

$this -> view -> assign( 'name', 'Bruno Augusto' );

E no Template, invcar:

 

<?php echo $this -> getVar( 'name' ); ?>

Esse eu tenho que concordar em partes, pois seu exemplo é válido e muito bem aplicado.

Mas discordo do uso de __set e __get quando um objeto precisa possuir seus atributos bem definidos e validados.

Se o uso for somente inserir e pegar o valor de um atributo, __set e __get são os mais recomendados. Mas caso dos atributos necessitarem serem validados, e ainda mais com o uso de exception, e manter um encapsulamento, não é nem um pouco recomendável. Também lembro de uma citação de um Engenheiro de Software sobre os métodos get e set (em geral, não métodos mágicos), ele falou que "Se os atributos não precisarem ser validados e você vai fazer get e set somente para ter, coloque os atributos como públic e evite mais métodos inúteis.

 

Como falei acima, nesse exemple, é o mais recomendável mesmo, pois não há como definir as variáveis em uma view. Mas há casos que eles não podem de maneira alguma serem utilizados.

 

De longe, acredito que os melhores métodos mágicos implementados foram: __construct(), __destruct(), __toString(), __clone().

 

Também não posso falar sobre os métodos __sleep() e __wakeup().

 

E ainda mais concordo com o que foi dito sobre os métodos __call em comparação com traits. Pra falar a verdade, até agora, a melhor implementação de traits que já vi, foi aqui no fórum com Singleton.

 

Acho que o que mais posso agregar ao tópico, é o fato de em determinados momentos alguns métodos mágicos serem extremamente úteis e em outros devem ser ignorados.