Métodos mágicos

[Bruno Augusto 417]

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.

Não sei até que ponto isso pode ser verdade.

 

Por exemplo, na minha View Engine eu tenho uma lista de Variáveis Reservadas cujo nomes não podem ser utilizados em Variáveis de Template, pois tais variáveis oferecem recursos "de fábrica" para ser usados no templates.

 

E dessa forma, eu tenho no método __set() uma verificação contra essa lista. Se por acaso o nome da variável desejada tiver restrições, uma Exception é disparada.

 

E tal Exception é automaticamente capturada pelo Dispatcher, parte do Front Controller, da aplicação, anulando qualquer possibilidade de loop infinito devido ao Exception Handler.

 

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.

Bom, relutei MUITO em acatar a "Lei" que propriedades NUNCA devem ser públicas. Quando finalmente entendi o real motivo e refleti sobre assunto, tive de dar o braço a torcer e concordar porquê isso é tão errado.

[Gabriel Heming 766]

Então, imagine criar o objeto PessoaFisica, e for inserir o CPF

 

Na minha concepção, os dados devem ser validados no set, e não na hora de inserir no banco de dados ou outros afins.

 

Então, com o __set, teria que verificar se foi inserida a variável cpf, que pode ser também CPF, Cpf ou até CpF. Isso se resolve com strcasecmp ou expressões regulares, sem problemas. Sem falar de quando "um cara que programa" (vide Willian Bruno) setaria PessoaFisica::cadastro_pessoa_fisica(). Pode ser que você criou toda a classe, documentou tudo, mas ninguém pode garantir que o "cara que programa" irá ler ou, e ao caso de ler, usar da forma correta.

 

Mas a cada __set você vai ter que fazer essa validação? Acho isso sem propósito, uma vez que implementado o método setCpf, só, e somente só, nele será inserido o CPF.

 

Bom, essa é a minha visão, para a validação de um cpf, e somente cpf, não é nada de mais, mas quando entram inúmeras validações e a cada validação você vai ter que verificar se o inserido é o necessário.

[visitante_php 0]

Pode ser que você criou toda a classe, documentou tudo, mas ninguém pode garantir que o "cara que programa" irá ler ou, e ao caso de ler, usar da forma correta.

dae as exceptions...

[Gabriel Heming 766]

Mas agora vem um dilema, o que é melhor, criar exceptions para tudo que pode ser inserido pelo método mágico ou apenas criar um método com sua devida exception?

 

Como falei anteriormente, varia com o objeto. Vai depender qual objeto, para ai sim, definir o que é melhor ou não. Isso ficou mais que claro.

[Bruno Augusto 417]

Então...

 

No meu caso, o __set() está implementado na View, que é utilizada quando as informações vêm do banco de Dados e não quando elas vão.

 

Quando elas vão, o __set() da vez seria o classe da Entidade e, ainda não me convenceram do porquê de validar os dados no Model, vejo tal processo de usabilidade doo Controller, por meio de um componente separado (no meu caso Validate)

 

Agora, se a validação tiver MESMO de ocorrer na Model, não convém usar __set(), senão uma lista enorme de condicionais deveria compor tal método para, baseado no valor do parâmetro (já que não há um tipo "CPF"), validar ou não.

 

E isso além der trazer uma tamanha repetição de código, indo contra os princípios do D.R.Y., ao meu ver, também viola a O.C.P. da classe e gera dependência, pois a Model teria de conhecer todos os campos que a compõe.

 

Nesse caso, acho o que o mais adequado seria um usar ambos, __set() para quem não precissa ser validado e um setter para quem precisar.

[visitante_php 0]

Mas agora vem um dilema, o que é melhor, criar exceptions para tudo que pode ser inserido pelo método mágico ou apenas criar um método com sua devida exception?

 

dae vem a engenharia de software, o planejamento...todo o planejamento influencia na programacao...nao adianta fazer um programa sem prever o q o usuario pode ou nao fazer...sempre tem akele usuario q se acha experto e sai testando as coisas pra mostrar q sabe mais q a TI...você nao sabe o nivel de instrucao da pessoa q vai usar o seu sistema, por isso documente, vai fazer manutencao documente...se o cara fez m***** ele vai ter q ler a documentacao...

[Gabriel Heming 766]

Bem que você comentou que os dados viriam do banco de dados.

 

Por exemplo, um sistema de matrícula para alunos que foi projetado por um analista enquanto eu trabalhei na TI de uma faculdade.

 

Quando o aluno efetivava a matrícula em um determinado curso. Ele primeiro criava os objetos (PessoaFisica(Aluno), Pessoa(Contratante), Contrato, Titulo, Lancamento, Matricula entre outros inúmeros objetos )

Nesse caso, quem deve validar os dados, é a própria classe que o objeto pertence. Você não precisa validar um cpf em um contrato, e sim, somente em uma PessoaFisica. Após todas as validações, era inserido no banco de dados. A complexidade é um pouco mais alta que só pegar um dado e colocar em um objeto ou retornar do banco de dados. Acho que ambos estamos pensando em casos diferentes para nossas "implementações"

 

-------

Complementação:

Apesar dos dados serem validados na hora de inserir no seu objeto e não na persistência, esses atributos podem não ser inseridos no objeto. Então essa validação deve ser feita na hora da persistência. Mas não validar se o atributo é valido ou não, e sim se ele existe ou não. No final, isso fica por mérito do banco de dados.

[hinom 5]

artigo de 2003 (inglês)

http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html

 

2012 (espanhol)

http://oopdesignmaderight.wordpress.com/2012/04/01/javabeans-o-el-peligro-de-la-convencion/

[visitante_php 0]

isso a eu tava pensando...se você usa mvc o set e get normal nao são tão necessários assim,a mas se você usa o 5 tiers ae a coisa muda...

[Gabriel Heming 766]

isso a eu tava pensando...se você usa mvc o set e get normal nao são tão necessários assim,a mas se você usa o 5 tiers ae a coisa muda...

Exatamente.

Por isso falei isso: "Acho que ambos estamos pensando em casos diferentes para nossas "implementações"".

 

E reforço mais o que eu falei antes sobre os métodos mágicos, vai do objetivo e aplicação de cada um. No meu caso (experiência) não era viável utilizá-los. No exemplo do Bruno Augusto, entretanto, era muito viável, mais fácil e foram bem implementados os métodos mágicos.