Boas práticas em Orientação a Objetos

Desenvolvedores, programadores e adeptos, ao desenvolver aplicações e sistemas, há algumas guias que nos ajudam a criar um bom código, fácil de manter, de entender e que outros programadores vão poder mexer caso necessário. O primeiro passo para isso é o uso de Orientação a Objetos. Mas mesmo dentro deste, há alguns conceitos importantes de serem colocados. Eis alguns pontos, ainda rascunhados, que é bom ter em mente:  

Uma bela interface em PHP 

  • Tempo
    • Fácil manutenção
    • Fácil de entender: O código é semântico, sem confusões e se auto-explica. Comentário apenas onde é necessário. O Código se auto-documenta.
    • Fácil de testar: Unidades simples, reuso, testes automatizados. É mais fácil testar pequenas unidades.
  • Modularidade
    • Acoplamento: Baixo acoplamento, permite melhores testes mais independência do código e maior reuso.
    • Dependência: Use apenas onde necessário.
    • Isolar mudanças: Segurança com testes. Mudanças de framework, de infraestrutura.
  • Não se exponha muito
    • Independência de implementação: Mudanças na implementação, no código de um método, não afeta o comportamento de onde usa este método.
    • Privado / Público: Propriedades privadas, assessores públicos. Protege as informações.
    • getters e setters: Muda a implementação, a fonte de dados, a regra de negócio. Ficam os assessores, a interface.
  • Responsabilidade
    • Sempre retorne algo significante: Evitar retornar null. Interface encadeada. No mínimo, retorne boleano.
    • Trate entradas inválidas: Não confie no resto do código. Valide sempre. Trate Nulos. (Especial foco em linguagem de tipo dinâmico/fraco)
    • Cuide de seus erros internamente: Use exceções com significado.
  • Interfaces
    • Exponha suas interfaces: Maior reuso, maior independência. Evitar acoplamento especifico.
    • Use interfaces com significado: Código é documentação.
  • Padrões
    • Pense em padrões: Resolver problemas de forma padronizadas. Nem sempre são os "Padrões de Projetos"(design patterns).
    • Use herança corretamente: Cuidado com armadilhas por facilidade de uso. Herança tem que fazer sentido. Evite BigFuckingClasses.
    • Use composição corretamente: Composição sobre herança. Corrente de responsabilidade, interfaces e acoplamento. 

Ficou bem confuso…e ainda existe muito mais. Eu uso a seguinte métrica para saber se a modelagem esta legal: Se eu consigo explicar de forma clara o por que de ser assim, é por que esta no caminho. Se complicar para explicar/desenhar o modelo, é por que esta ruim.

3 ideias sobre “Boas práticas em Orientação a Objetos

  1. Bati o olho na imagem e tive faniquitos: precisei colocar 2 assistentes meus pra fazer documentação de controllers e services de uma aplicação java (e olha que minha equipe nem trabalha com isso, cuidamos da parte de interface/front-end) em javadoc…d e código de, tipo, 2 anos atrás. Pq os programadores java não o fizeram e um cliente preciava. Foi bom meu Natal/Ano-novo… hehe

  2. Documentar enquanto desenvolvemos é normal, mas documentar(doc-comentar?) depois que o sistema esta pronto, sem ser manutençao e tal, é uma ME***! Nem imagino em um sistema que nem foi feito por vcs. Mas que presentão hein, hehe.

  3. O bizarro na verdade é ter que documentar algo que você não fez, que não é nem da tua área, só pq o dono da empresa precisa dessa documentação ASAP… hehe

Comentários encerrados.