Padrões de Projeto
Conceitos preliminares:
- Classe:
- Objeto:
- Associação:
- Agregação:
- Composição:
- Coesão:
- Acoplamento:
- Princípios de Design de Robert C. Martin:
-
Single Responsibility Principle: Este princípio diz que cada classe deve ter apenas uma responsabilidade[1]. Quando várias responsabilidades são agregadas em uma única classe, mudanças em uma destas pode ocasionar problemas com as outras responsabilidades.
-
Open/Closed Principle: Entidades de software (classes, módulos, funções, etc) devem ser abertas para extensão mas fechadas para modificações.
-
Liskov Substitution Principle: Objetos em um programa devem ser substituíveis com instâncias de seus subtipos sem alterar a corretude desse programa.
-
Interface Segmentation Principle: Muitas interfaces específicas do cliente são melhores do que uma interface de propósito geral.
-
Dependency Inversion Principle: Deve-se depender de abstrações, não de concreções. Ou seja, classes de um nível alto de abstração não devem depender de classes de um nível mais baixo.
- Tipos de padrão:
-
Padrões de criação: Abstraem o processo de instanciação. Eles ajudam a tornar um sistema independente de como seus objetos são criados, compostos e representados. Um padrão criacional de classe usa herança para variar a classe que é instanciada, enquanto um padrão criacional de objeto delegará a instanciação para outro objeto.
-
Padrões estruturais: Os padrões estruturais estão preocupados com a forma como as classes e os objetos são compostos para formar estruturas maiores. Os padrões de classe estrutural usam herança para compor interfaces ou implementações. Em vez de compor interfaces ou implementações, os objetos de padrões estruturais descrevem formas de compor objetos para realizar novas funcionalidades.
-
Padrões comportamentais: Os padrões comportamentais estão preocupados com os algoritmos e a atribuição de responsabilidades entre objetos, descrevem não apenas padrões de objetos ou classes, mas também os padrões de comunicação entre eles. Esses padrões caracterizam o fluxo de controle complexo que é difícil de seguir em tempo de execução, deslocam seu foco para longe do fluxo de controle para permitir concentração apenas na forma como os objetos estão interligados. Utilizam herança para distribuir o comportamento entre as classes.
Classe é um conceito orientado a objeto que encapsula dados e abstrações procedurais necessárias para descrever o conteúdo e comportamento de alguma entidade do mundo real (PRESSMAN, 2011).
Por definição, objetos são instâncias de uma classe específica e herdam seus atributos e propriedades disponíveis para manipular os atributos (PRESSMAN, 2011).
Uma associação indica que um objeto contém ou que está conectado a outro objeto. Associações possuem diversas características importantes: multiplicidades (indica quantos objetos podem tomar parte na instância de uma associação), nome (é um nome que descreve o relacionamento), direção de leitura, papéis (parte que um objeto desempenha em um relacionamento), tipo de participação e conectividade (SINTES, 2002).

No diagrama de classes em UML acima, tem-se um exemplo de associação entre a classe Pessoa e a classe Banco, o diagrama mostra que uma pessoa 'empresta de' um banco, onde 'empresta de' é o nome da associação, a seta indica a direção da associação. No exemplo, o papel da Pessoa é devedor e o do Banco é credor, e a notação de multiplicidade informa que um banco pode ter um ou mais devedores (1..*) e que uma pessoa pode usar 0 ou mais bancos (*).
Uma agregação é um tipo associação que modela um relacionamento 'tem um' ou 'parte de' entre pares. Esse relacionamento significa que um objeto contém outro. Pares significa que um objeto não é mais importante do que o outro (SINTES, 2002).

No diagrama de classes em UML acima, um Banco pode conter qualquer número de objetos Cliente. O losango aberto indica qual objeto é o todo e qual é a parte. Aqui, o losango diz que o Banco é o todo. Banco é a classe que 'tem um' no relacionamento, um objeto Banco contém objetos Cliente. Em termos de programação, isso poderia significar que Banco contém um array de objetos Cliente.
Uma composição é um pouco mais rigorosa do que a agregação, não é um relacionamento entre pares, ou seja, na composição os objetos não são independentes uns dos outros (SINTES, 2002).

No diagrama de classes em UML acima, um Banco pode conter muitos objetos Filial. O losango fechado diz que esse é um relacionamento de composição e também diz quem 'tem um'. Neste caso, Banco 'tem um', ou contém, objetos Filial. Como esse é um relacionamento de composição, os objetos Filial não podem existir independente do objeto Banco. A composição diz que, se o banco encerrar suas atividades, as filiais também fecharão. Entretanto, o inverso não é necessariamente verdade. Se uma filial fechar, o banco poderá permanecer funcionando.
A coesão é uma medida do quão fortemente relacionadas e focalizadas são as responsabilidades de uma classe (BEZERRA, 2015).
O acoplamento é uma medida do quão fortemente uma classe está conectada a outras classes, tem conhecimento ou depende das mesmas (BEZERRA, 2015).
Os princípios de Design Orientado a Objetos SOLID, acrônimo para os cinco princípios básicos de Design OO introduzidos por Robert C. Martin, são:
Um design pattern ou padrão de projeto é uma solução geral para problemas frequentes dentro do desenvolvimento de um projeto de software, portanto não é uma solução pronta, mas sim uma descrição ou modelo para ser aplicado de acordo com o problema a ser resolvido. Os padrões são divididos em três tipos:
Design Patterns:
Padrões de criação:
Padrões estruturais:
Padrões comportamentais:
- 13. Chain of Responsibility
- 14. Command
- 15. Interpreter
- 16. Iterator
- 17. Mediator
- 18. Memento
- 19. Observer
- 20.State
- 21. Strategy
- 22. Template
- 23. Visitor
Padrões de Arquitetura:
