PHP Uso dos métodos __get e do __set

>

Citar

netbeans começou alertar que a classe deveria ter no máximo 200 linha.

Oush.

Tem sentido isso?

Já vi alguns argumento a respeito de JavaScript por deixar no cache do navegador, mas linguagem php desconheço.

Será q tem a ver com esse padrão?!

https://www.youtube.com/watch?v=gB5Gej0O400&t=121s

(Recomendo fortemente esse canal)

>

Citar

O melhor caminho não seria, refatorar a classe em classes menores ou esta é um boa pratica de programação?

O tamanho da classe não interefere em boa ou má pratica e sim como está estruturado o seu projeto.

Alguns principios pro exemplo SOLID:

http://forum.imasters.com.br/topic/510435-solid-principio-da-responsabilidade-unica/

https://pt.wikipedia.org/wiki/Injeção_de_dependência

Da uma lida tmb nesse post, parece bastante com seu contexto.

https://forum.imasters.com.br/topic/545070-como-implementar-solid-sem-violar-seus-principios/

Se quiser posta seu código, a galera com mais tempo de vivência em O.O. pode dar um help

Hoje quando alguém cita qualidade de código lembro dos Design Patterns,

- Factory Method

- Abstract Factory

- Simple Factory

- Bridge

- Builder

- Composite

- Adapter

- Chain Of Responsability

- Strategy

- Proxy

- Dependency Injection

- Singleton

Nossa, quanta informação boa!

Repensei bastante nas varias possibilidades de refatorar o código.

Algumas coisas, não conhecia e tive estudar outras ainda estou abstraindo?

Estou postando parte do Código para caso queiram olhar ou dar algumas sugestões.

Este código foi gerado com base no livro PHP - Programando com Orientação a Objeto.

Se tiverem algumas dicas de outros livros, agradeço.

<?php
class Maquinas extends Classe {

 private $id;
 // equipamento
 private $nome;
 private $dataCadastro;
 private $dataInstalacao;
 private $responsavel;
 private $destinacao;
 // hardware 0/5
 private $especificacao;
 private $marca;
 private $modelo;
 private $serialNumber;
 private $patrimonio;
 // software 0/2
 private $so;
 private $software;
 private $softwarePrincipal;
 private $softwareAdicionais;
 // Rede 0/5
 private $ip;
 private $nomeServidor;
 private $localLogico;
 private $alias;
 private $monitoramentoWhatsup;
 // Infra
 private $tensao;
 private $amper;
 // Aquisição/Lotação/Convenio
 private $especificacao;
 // Assistencia Técnica 0/7
 private $processo;
 private $empresa;
 private $telefone;
 private $situacao;
 private $inicioVigencia;
 private $fimVigencia;
 private $valor;
 // informações adicionais 0/1
 private $infoAdicionais;
 // não agrupados
 private $switch;
 private $contrato;
 private $assinatura;
 private $observacao;

 public function __construct() {
 parent::__construct();
 }

	// método que faz o mapeamento para auxiliar na geração de SQL baseado no livro
 // foram feitas alterações para auxiliar na geração de formulários
 // e para que consiga obter os atributos do objetos com nome diferente da coluna da tabela.
 // cada chamada de método aqui, penso em criar um objeto para criar uma agregação/composição não sei ainda.
 protected function defineCampos() {
 $this->getCampos()->addCampo("id", "codigo", true, "cod");
 $this->addCamposEquipamentos();
 $this->addCamposHardware();
 $this->addCamposSoftware();
 $this->addCamposRedes();
 $this->addCamposInfra();
 $this->addCamposAssistencia();
 $this->getCampos()->addCampo("infoAdicionais", "Informações Adicionais", true, "outrasi");
 $this->addCamposNaoAgrupados();
 }

 private function addCamposEquipamentos() {
 $this->getCampos()->addCampo("id", "Grupo", true, "grupo");
 $this->getCampos()->addCampo("nome", "id", true, "nome");
 $this->getCampos()->addCampo("dataCadastro", "Data de Recebimento", true, "datac");
 $this->getCampos()->addCampo("dataInstalacao", "Data de Instalação", true, "datai ");
 $this->getCampos()->addCampo("responsavel", "Responsável", true, "resp");
 $this->getCampos()->addCampo("destinacao", "Destinação", true, "destina");
 }

 private function addCamposHardware() {
 // ...
 }

 private function addCamposSoftware() {
 // ..
 }

 private function addCamposRedes() {
 // ..
 }

 private function addCamposInfra() {
 // ..
 }

 private function addCamposAssistencia() {
 // ..
 }

 private function addCamposNaoAgrupados() {
 // ..
 }

 // gets and sets

}

A classe acima de cara já viola o 1º principio do S.O.L.I.D. que é a SRP " Single responsibility principle", divida sua classe em domínios.

É melhor ter varias classes desacoplando seu objetos, do que uma tentando fazer tudo.

SOLID – Teoria e Prática – Demo + Vídeo
http://www.eduardopires.net.br/2015/01/solid-teoria-e-pratica/

>

18 horas atrás, targa disse:

Classe deveria ter no máximo 200 linha.

Meus código não passa disso, porem não utilizo Getters And Setters

De uma olhada aqui no post

PHP “deep in”: visibilidade, relevância de atributos e meta programação

>

Em 22/03/2017 at 18:03, targa disse:

-
Apesar de ter toda a estrutura, isto seria mesmo Orientação a Objeto? Não seria o mesmo que tornar os atributos publico, uma vez que você chama "$classe->atributo"?

Continua sendo Orientaçao a Objetos (considerado, por alguns, obscurecimento da POO) . Entretanto, isso faz parte da meta programação.

http://pt.stackoverflow.com/questions/22398/o-que-é-metaprogramação

>

Em 22/03/2017 at 18:03, targa disse:

-
O melhor caminho não seria, refatorar a classe em classes menores ou esta é um boa pratica de programação?

Sempre deve ser refatorado em classes menores. O S.O.L.I.D., que já foi mencionado, define várias regras para isso. Outro, que gosto de lembrar, são sobre Object Calisthenics. O conceito é vindouro do Java (do livro The ThoughtWorks Anthology) e foi migrado para o PHP pelo Guilher Branco e Rafael Dohms:

https://pt.slideshare.net/guilhermeblanco/php-para-adultos-clean-code-e-object-calisthenics

>

Em 22/03/2017 at 18:03, targa disse:

-
O que acontece com os recursos de autocompletar, tem com ativá-los?

Não há como ativar, pois, do ponto de vista da meta programação, são irrelevantes.

Entretanto, apenas dizer que um classe não pode ter setters e getters é muito abrangente. A regra que, na minha opnião, melhor define quando uma classe deve ou não possuir tais métodos é a Tell, don't ask. A qual você pode ler na regra número 9 de Object Calisthenics  ou nos links abaixo:

http://wiki.c2.com/?TellDontAsk

https://pragprog.com/articles/tell-dont-ask

Outro ponto, sobre o limite de linhas, acaba sendo uma irrelevante, pois uma vez que tenha em mente como deve-se abstrair uma classe, raramente ela irá ficar "inchada". Com exceções para classes de regras de negócio, que essas podem sim ignorar certas regras devido a alta complexidade.

Assim como a meta programação, você irá encontrar N paradigmas com seus prós e contras. Ao meu ver, a meta programação gera agilidade e redução de repetição de código. Entretanto, é obscura quanto ao que um participante pode ou não fazer. Como, por exemplo, documentação a nível de código (PHPDocumentor, IDEs, etc...), correspondência de modelagem (a modelagem é apenas "similar" ao que é implementado).

Outro pronto, é sobre como o desenvolvedor espera que o código se comporte e como o sistema pode se comportar. Isso você pode verificar no exemplo abaixo (básico, mas ainda válido):