Design patterns
Quatro desenvolvedores (Erich Gamma, Richard Helm, Ralph Johnson e
John Vlissides) conhecidos como a gangue dos 4, criaram o livro Design
Patterns: Elements of reusable object-oriented software, e esse livro identificou
e listou os padrões no desenvolvimento de softwares.
Design Patterns clássicos:
Os primeiros padrões identificados foram os seguintes:
Os padrões de criação se preocupam com o processo de criação de
objetos. Já os estruturais se preocupam com a composição de classes ou de
objetos. Por fim, os comportamentais definem a maneira como classes ou
objetos deverão se comportar.
Design Patterns de Criação:
🡺 Factory Method:
Seu propósito é criação e o seu escopo é classe. Também
conhecido como Construtor Virtual, seu objetivo é criar uma “fábrica”
de classes em tempo de execução e deixar que a classe decida seu
tipo dinamicamente. Para que isso aconteça, o Factory Method
dispõe uma interface, e são as subclasses que decidirão qual classe
concreta deverá ser instanciada.
Como podemos ver nas classes anteriores temos uma interface
genérica e temos uma classe concreta que sobrescreve os métodos
da interface, ok, mas isso é apenas Programação Orientada a
Objetos, onde entra o Factory Method?
O Factory Mehod entra exatamente na criação dos objetos
dependentes da interface IPersonagem:
É a partir do método Escolher_Personagem que o factory pode
ser usado:
Veja essa lógica só funciona através do Polimorfismo pois usamos
o tipo genérico IPersonagem mas iremos instanciar as suas classes
filhas.
🡺 Abstract Factory:
Seu propósito é criação e o seu escopo é objetos. O objetivo
desse Pattern é agrupar diversas factories que possuam
características semelhantes utilizando uma interface.
Imagine que eu tenho duas interfaces que são parecidas:
E cada uma delas tenha os seus objetos:
A partir dessas classes nós podemos criar uma interface para
criar a fábrica que irá gerar determinados objetos, exemplo imagine
que temos uma classe de IEnergia específica e que quando for
criado o seu objeto uma outra classe de IRevestimento deve ter o
seu objeto criado, para criar esse relacionamento de criação nós
usamos uma fábrica que une as duas criações:
Assim temos um relacionamento de criação entre as fabricas dos
objetos.
🡺 Singleton:
Seu proposito é criação e o seu escopo é objeto. O
objetivo desse padrão é garantir que apenas uma única instância
de um objeto seja criada.
Para fazer isso usamos do atributo static e usamos o
construtor da classe como privado e estático e setado através de
outro método:
Perceba que pela POO essa classe não pode ser passada como
herança e para você não tem acesso direto a instancia da classe, você deve
usar o método GetInstancia que só possibilita a criação da instancia se ela
ainda não existir, na pratica a instancia só será criada uma única vez:
Perceba que a criação da instancia referenciada pelo console “Bola em
jogo” só foi executada uma única vez.
🡺 Builder:
Seu propósito é criação e está no escopo de objeto. O
Builder atua na construção de objetos trazendo a metodologia de
construção por partes.
Para usarmos o padrão Builder primeiro criamos uma
classe abstrata que servira de base para as demais classes e
objetos:
Veja os métodos set dos atributos são protected, mas
poderiam ser private, o sentido do método set ter um desses dois
modificadores de acesso é para limitar a modificação dos
atributos a um método customizado para cada subEntidade
derivada dessa classe.
Agora precisamos criar a classe abstrata para criar os
objetos das classes de soldados, essa classe será estendida via
herança para outras classes de criação únicas:
Agora devemos criar a classe que será responsável por criar um
soldado:
A partir disso temos um builder de um “exército” eu serve para criarmos
os seus “soldados”:
🡺 Prototype:
O seu proposito é criação e o seu escopo é objeto. Esse padrão
permite copiar objetos existentes sem que seu código seja dependente
da classe.
Primeiro precisamos criar uma classe abstrata que servira de
molde para as demais classes:
Agora criamos uma classe concreta:
Agora vamos criar uma classe para gerenciar as nossas classes:
Agora através do nosso gerenciador podemos usar o prototype na
prática:
