Validações no Construtor
Dizem que um Objeto não pode ter um estado inválido e que sua validação deve ser feita no seu Construtor, ou seja, se os argumentos do Construtor não são suficientes, não deveríamos criar o Objeto.
Imagine um mundo onde tudo são objetos.
Como você irá verificar se um Objeto é inválido antes de você criá-lo?
Decorator Pattern
Como agregar responsabilidade a Objetos individuais, em tempo de execução, independente de sua Classe?
Utilizando Decorator Pattern.
Os Decoradores oferecem uma alternativa simples e flexível ou uso de subclasses para extensão de funcionalidades.
Nomeando Classes
O nome de uma Classe deve significar quem ela representa e não o que ela faz.
Não utilize nomes como Validador, Leitor, Controlador, Parser, Executor, Manager, Handle, etc. Esses nomes dizem o que fazem, não o que são.
Não Utilize Casting
Sua equipe precisa de um programador Object Pascal para trabalhar num projeto que está sendo codificado em FreePascal. Este projeto terá integração com um ERP codificado em Java e um website codificado em PHP. Tudo utilizando MS SQLServer como SGBD.
Como você iria descrever o anúncio dessa vaga?
Não Utilize nil ou NULL
O conceito NULL, também conhecido como “O erro de 1 bilhão de dólares”, foi inventado por Charles Antony Richard Hoare em 1965.
Em uma conferência em 2009, ele pediu desculpas por inventar a referência nula.
Mas o estrago já havia sido feito…
Objetos sem Estado
Por que sempre deveríamos criar nossas Classes com pelo menos um argumento no construtor principal afim de não deixar nossos Objetos “vazios de estado”?
Porque construtores sem argumentos é um anti-padrão.
AWS Lib: A História e o novo suporte a SES
Você já conhece o projeto OpenSource AWS Lib?
AWS Lib é uma implementação minimalista para Amazon Web Services (AWS). Inicialmente foi implementada somente a API para a utilização de apenas um dos serviços, o Amazon S3, até agora…
Construtores da Classe, Primário e Secundários
Você pode implementar dezenas de Construtores para uma única Classe, porém apenas um deles deverá ser o Primário enquanto os demais deverão ser apenas Secundários.
Todos os construtores Secundários deverão fazer uma chamada ao construtor Primário.
Objetos pensam e tomam decisões
Se você Pensar em Objetos ou invés de pensar em procedimentos e funções conseguirá implementar um código onde os Objetos conversam entre si ao invés de utilizar Programação Procedural que instrui o compilador sobre o que fazer linha-a-linha.
Não fazemos isso na Orientação a Objetos. Seu Objeto sabe o que fazer. Ele não precisa de um “controlador” (você) para lhe dizer o que fazer. Ele sabe. Ele foi contratado pra isso. Deixe-o trabalhar.
Classes devem Implementar apenas uma Responsabilidade
O Princípio da Responsabilidade Única (Single Responsibility Principle) afirma que, se tivermos mais de uma razão para mudar a implementação de uma Classe, devemos dividir o comportamento em duas ou mais Classes.
Objetos devem representar Entidades reais
Tudo que existe fora do Contexto do software é uma Entidade que existe na vida real e deve ser representada por um Objeto dentro do programa.
Defina Classes que implementem abstrações de Entidades reais.
DataModule é apenas um recipiente, e só isso
Não utilize um DataModule como uma Classe de Negócio, implementando métodos públicos e utilizando-o como um Singleton. Isso é errado. Você deixará seu sistema acoplado a esta única implementação e não será possível testá-lo da maneira correta.
Um DataModule não deve conter Regras de Negócio.
Não utilize Métodos Estáticos
Objetos são representações de Entidades vivas. Quando solicitamos uma tarefa a um Objeto, ele mesmo irá executar ou repassar a tarefa à outro Objeto.
Utilizando Métodos Estáticos, qual Objeto irá executar a tarefa? Nenhum. A tarefa será executada pelo Método Estático da Classe e nenhum Objeto estará envolvido.
Método Estático é uma herança da programação Procedural.
Interfaces e a Referência Circular entre Objetos
Um Autor escreveu um Livro. Um Livro tem um Autor… que escreveu um Livro, que tem um Autor…
Um Objeto A aponta para um Objeto B e este aponta para o Objeto A. Esses Objetos, baseados em Interfaces com contagem de referência, nunca serão desalocados da memória automaticamente pelo compilador.
O nome desse problema é denominado Referência Circular e ele não ocorre apenas no Object Pascal.
FreeAndNil... Esqueça
Se você utiliza o paradigma da Orientação a Objetos corretamente, você não precisa utilizar FreeAndNil… você não precisa nem mesmo utilizar o método Free!