Olá, se você chegou até aqui é porque estava procurando por boas práticas de programação, então vamos lá!
Vamos falar mais um pouco sobre boas práticas de programação e revisar o assunto de SOLID
Este vai ser mais um post sobre boas práticas de programação em PHP, este texto que foi escrito para o blog da Geek Hunter neste post.
“Meça duas vezes corte uma vez só.”
Harrison Ford.
Porque falar de boas práticas e não do mais novo framework do mercado? (Desde já fica aqui ressalva de que não é uma afirmação para desencorajar o uso de frameworks.)
Nós vamos falar de boas práticas porque isso pode agilizar — e muito — o dia de alguém, além de evitar que erros minem a produtividade.
E, claro, falar de boas práticas é sempre oportuno e necessário para o desempenho futuro do que quer que seja estejamos construindo.
Vamos lá!
Dicas ser eficiente ao programar em PHP
Busque boas referências de programação em PHP
Bom, para começar quero apenas reforçar o que provavelmente você já deve ter ouvido, mas que vale ser relembrado: fique sempre atento(a) às referências. Qual o seu canal de informação hoje?
Uma de nossas referências primárias deve ser o manual da própria linguagem. No nosso caso, Manual do PHP. Aqui tem muita documentação da linguagem.
Outra referência interessante feita pela comunidade PHP, pode ser encontrada por esse link que indico.
Use as versões suportadas do PHP
Use sempre uma versão atualizada do PHP.
Atualmente, recomendado-se usar o PHP a partir da versão 7.1.
É importante frisar que cada versão do PHP é suportada por 3 anos e, após isso, ela entra no fim do ciclo de vida. Aqui você consegue consultar versões suportadas PHP.
Boas práticas de código com SOLID
SOLID é uma abreviação para cinco princípios de boas práticas em desenvolvimento de software orientado a objetos. As boas práticas foram divulgados por Robert C. Martin, autor do famoso livro Código Limpo.
Single Responsability – Responsabilidade única.
Este princípio define que uma classe deve ter uma única responsabilidade. Isso facilita muito o teste e manutenção de nossas classes.
Um exemplo da quebra desse princípio é o método — bem usado, inclusive — para validar os dados de uma classe. Esse método faz com que os dados sejam atualizados no banco de dados também.
É importante lembrar que são 2 coisas com responsabilidades distintas e devem estar separadas.
Open Closed – Aberto Fechado.
Esa segunda ideia propõe que uma classe deve estar aberta para ser estendida/herdada, mas que precisa estar fechada para que as alterações sejam realizadas.
Fazendo isso, outras classes podem herdar e reutilizar o seu conteúdo sem ter que alterar o comportamento da classe pai. Este é um exemplo bem básico, mas em que é possível ver o conceito.
A partir da Interface ‘Animal’ podemos implementar outros animais, lembrando que a interface obriga a implementação de todos os métodos.
<?php
interface Animal {
public function emitirSom();
}
class Cachorro implements Animal {
public function emitirSom() {
echo "latir";
}
}
class Pato implements Animal {
public function emitirSom() {
echo "quack quack";
}
}
?>
Liskov Substitution Principle – Substituição de Liskov
Este princípio recebe o nome de sua autora, Barbara Liskov, uma cientista da computação e professora do MIT
Se quiser saber mais sobre ela, aqui está o perfil de Barbara Liskov no Wikipedia.
A ideia deste princípio é a seguinte:
Objetos em um programa devem ser substituídos por instâncias de seus subtipos, sem alterar a funcionalidade do programa.
Ficou complicado ? Vamos melhorar isso:
A classe filha, que estende o comportamento de uma outra classe, não pode alterar, tornar mais restrito a implementação de um recurso da classe pai.
Isto nos faz repensar o uso da herança, e vemos que a ideia anterior de ‘aberto para extensão’ e ‘fechar a alteração’ está ligada com esse princípio de substituição de Liskov.
O exemplo clássico da quebra desse padrão acontece com a implementação da classe Quadrado, que estende a classe Retângulo.
Na geometria todo quadrado é um retângulo, então implementamos a classe Quadrado a partir da classe Retângulo, mas com a alteração para que ambos os lados sejam iguais.
class Retangulo {
private $altura;
private $largura;
public function getAltura() {
return $this->altura;
}
public function getLargura() {
return $this->largura;
}
public function setAltura($valor) {
$this->altura = $valor;
}
public function setLargura($valor) {
$this->largura = $valor;
}
public function calcularArea() {
return "A area é ". $this->getAltura() * $this->getLargura();
}
}
class Quadrado extends Retangulo {
public function getAltura() {
return $this->altura;
}
public function getLargura() {
return $this->largura;
}
public function setAltura($valor) {
$this->altura = $valor;
$this->largura = $valor;
}
public function setLargura($valor) {
$this->largura = $valor;
$this->altura = $valor;
}
public function calcularArea() {
return parent::calcularArea();
}
}
Ao testarmos esse código, teremos a prova de que essa implementação não simulará o comportamento esperado do cálculo da área.
Isso demonstra que não vai ser correto dizer que a classe Quadrado é uma classe Retângulo e também temos a quebra do princípio de Liskov.
Interface Segregation/Principle Segregação.
A correta aplicação dessa ideia está totalmente ligada a encontrar a abstração correta do comportamento da nossa implementação.
Exemplo 1:. ISS, IR, IPI. Todas essas siglas são impostos.
Exemplo 2:. Gato, cachorro, papagaio. Todas essas palavras representam animais.
Com esses exemplos, vamos pensando sobre a abstração e como melhor implementar a nossa solução em orientação a objetos.
Dependency Inversion Principle – Inversão de dependência.
Este último princípio propõe que as classes devem depender de abstrações.
Abstrações não devem depender dos detalhes, mas os detalhes dependem da abstração.
Classes de alto nível não dependem das classes de baixo nível. O correto é que ambos dependam de abstrações.
Vejamos o clássico exemplo da implementação do botão de lâmpada:
<?php
class Botao {
private $lampada;
public function __construct(Lampada $lampada) {
$this->lampada = $lampada;
}
public function Acionar() {
if (!$this->lampada->ligado) {
$this->lampada->ligar();
}
}
}
Esta implementação quebra o princípio de inversão de dependência, pois a classe Botão depende da classe lâmpada.
O Botão sabe os detalhes da implementação. Alterações na classe lâmpada também irão requerer alterações na classe Botão.
Faremos uma abstração e para melhorar esta implementação com a inversão de dependência.
interface Dispositivio {
public function ligar()
public function desligar()
}
class Lampada implements Dispostivo {
public function ligar() {
}
public function desligar() {
}
}
class Botao {
private $dispositivo;
public function __construct(Dispositivo $dispositivo) {
$this->dispositivo = $dispositivo;
}
public function Acionar() {
if (!$this->dispostivio->ligado) {
$this->dispositivo->ligar();
}
}
}
Teste seu software
“Você não tem nada a perder, a não ser os seus bugs”
Steve Freeman.
Não é apenas uma boa prática, mas digamos que seja essencial para a qualidade, evolução e redução de custos com desenvolvimento de software.
Alguns questionam a adoção dessa prática por demandar mais tempo no desenvolvimento.
Essas pessoas não estão levando em conta que o desenvolvimento guiado a testes nos proporciona qualidade no produto final.
Exemplos de testes que podem ser feitos em uma aplicação: Testes unitários, Testes de integração e Testes funcionais.
Testes unitários validam se as nossas classes, métodos e funções estão funcionando conforme o esperado.
Sua metodologia funciona em cima do conceito de primeiro escrevermos o teste, antes da implementação do sistema.
Em resumo, os testes nos garantem que as nossas funcionalidades estão operando corretamente e nos levando ao próximo passo, que é testar a integração desses componentes por meio, logicamente, de testes de integração.
Essas são algumas boas práticas que escolhi dividir com vocês neste artigo. Existem diversas outras que você pode adotar também. O objetivo é incentivar o bom desenvolvimento de software e a busca por outras boas práticas.
