Bertrand Meyer descreve as pré e pós-condições de uma operação como design por contrato. Invariantes são condições que todo objeto de uma determinada classe deve satisfazer em todo ciclo de vida, enquanto estiver em equilíbrio, isto é, não estiver numa mudança de estado.
Um exemplo de invariante, dado por Page-Jones é sobre um objeto da classe Triangulo.
Interfaces são outra forma de design por contrato. Quando uma determinada classe afirma que implementa uma interface, ela deve, obrigatoriamente, implementar todas as operações que estão definidas nesta interface. Existe um excelente artigo aqui sobre o assunto.
Enfim, invariantes, pré e pós-condições e interfaces formam uma abordagem de design conhecida como "Design por Contrato". Esta abordagem garante que uma operação de um dado objeto vai gerar a resposta correta, para o objeto cliente (objeto que está consumindo o serviço), ao mesmo tempo que obriga o objeto cliente a obedecer as pré-condições do serviço que está consumindo. Também obriga a implementação das operações que estão definidas na interface implemetada.
Referência: Fundamentals of Object-Oriented Design in UML by Meilir Page-Jones
Um exemplo de invariante, dado por Page-Jones é sobre um objeto da classe Triangulo.
Sabendo que os lados de um triângulo são Triangulo.a, Triangulo.b, Triangulo.c, então uma parte da invariante de classe de Triangulo é: a + b > c and b + c > a and c + a > b.A pré-condição é uma condição que deve ser verdadeira antes do início da execução da operação. Se não for, a operação pode recusar executar e lançar alguma excessão. Uma pós-condição é uma condição que deve ser verdadeira no fim da execução da operação.
Interfaces são outra forma de design por contrato. Quando uma determinada classe afirma que implementa uma interface, ela deve, obrigatoriamente, implementar todas as operações que estão definidas nesta interface. Existe um excelente artigo aqui sobre o assunto.
Enfim, invariantes, pré e pós-condições e interfaces formam uma abordagem de design conhecida como "Design por Contrato". Esta abordagem garante que uma operação de um dado objeto vai gerar a resposta correta, para o objeto cliente (objeto que está consumindo o serviço), ao mesmo tempo que obriga o objeto cliente a obedecer as pré-condições do serviço que está consumindo. Também obriga a implementação das operações que estão definidas na interface implemetada.
Referência: Fundamentals of Object-Oriented Design in UML by Meilir Page-Jones
Parte I - Introdução
Parte II - Correção
Parte IV - Flexibilidade
Parte V - A Lei de Demeter
Parte VI - Eficiência
Parte VII - Coesão
Parte VIII - Usabilidade
Parte IX - Relacionamento entre classes
Parabéns pelo blog e pelo link. Conteúdos bem diretos e úteis!
ResponderExcluirObrigado Hugo!
ResponderExcluir