Padrões de design

1.1 Introdução aos padrões

Conforme mencionado anteriormente, um programador começa a trabalhar em um programa projetando seu modelo: compilando uma lista de entidades nas quais o programa irá operar. E quanto mais entidades no programa, mais complexo o programa.

Portanto, para reduzir a complexidade do programa, eles tentam padronizar as interações dos objetos. E é aqui que os padrões de projeto ou padrões de projeto ajudam muito o programador . Do padrão de design inglês .

Importante! Em russo, a palavra design geralmente significa design gráfico, em inglês não é o caso. A palavra inglesa design tem um significado mais próximo da palavra “design” e/ou “dispositivo”. Por exemplo, o design de um motor não é sua aparência, mas sua estrutura interna.

Portanto, um padrão de design é exatamente um padrão/padrão de design. Eu recomendo que você pare de usar a palavra design no sentido de “aparência”. Você é o futuro Engenheiro de Software, e para você design é exatamente design.

Então, o que é esse padrão de design? Em primeiro lugar, um padrão de projeto é uma solução padrão para um problema padrão . Uma solução boa, eficaz e testada pelo tempo.

Digamos que lhe pediram para projetar uma bicicleta, você pode fazê-la com duas rodas, três ou até cinco. Então, a propósito, no início do design, era. Mas a abordagem testada pelo tempo é duas rodas. Mas a abordagem óbvia atual passou por dor e erros:

Normalmente, um modelo não é uma solução completa que pode ser convertida diretamente em código, é apenas um exemplo de uma boa solução para um problema que pode ser usado em várias situações.

Padrões orientados a objetos mostram relacionamentos e interações entre classes ou objetos , sem especificar quais classes finais ou objetos do aplicativo serão usados.

1.2 História dos padrões de projeto

Nos anos 70, os programadores se deparavam com a necessidade de desenvolver grandes programas que precisavam ser trabalhados por equipes de desenvolvimento inteiras. Vários métodos de organização do trabalho foram tentados, mas a indústria da construção influenciou mais o desenvolvimento.

Para organizar o trabalho de um grande grupo de pessoas, foram utilizadas práticas e abordagens da indústria da construção. Aliás, foi a partir daí que termos como assembly (build), Software Developer (builder) e o conceito de arquitetura entraram na programação.

E como você pode imaginar, a ideia do padrão de projeto também foi tirada da indústria da construção. O conceito de padrões foi descrito pela primeira vez por Christopher Alexander em The Pattern Language. Cidades. Prédio. Construção". Neste livro, uma linguagem especial, padrões, foi usada para descrever os processos de projeto da cidade.

Padrões de construção descreviam decisões típicas testadas pelo tempo: qual deveria ser a altura das janelas, quantos andares deveria haver no prédio, quanta área no microdistrito deveria ser alocada para árvores e gramados.

Portanto, não é de surpreender que em 1994 o livro “Técnicas de Design Orientado a Objetos. Design Patterns”, que inclui 23 padrões que resolvem vários problemas de design orientado a objetos.

O livro foi escrito por 4 autores: Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. O título do livro era longo demais para alguém se lembrar. Portanto, logo todos começaram a chamá-lo de “livro da gangue dos quatro”, ou seja, “livro da gangue dos quatro” , e depois até “livro GoF”.

E desde então, outros padrões de design foram descobertos. A abordagem de “padrão” tornou-se popular em todas as áreas de programação, então agora você pode encontrar todos os tipos de padrões fora do projeto de objetos.

Importante! Os padrões não são algumas soluções super originais, mas, ao contrário, soluções típicas frequentemente encontradas para o mesmo problema. Boas soluções comprovadas.

1.3 Lista de padrões

Muitos programadores não aprenderam um único padrão em toda a vida, o que, no entanto, não os impede de usá-los. Como dissemos antes, os padrões são boas soluções testadas pelo tempo e, se o programador não for tolo, com a experiência ele próprio encontrará essas soluções.

Mas por que, por meio de dezenas de tentativas e erros, chegar a soluções ótimas quando há pessoas que já passaram por esse caminho e escreveram livros com a quintessência de sua experiência e sabedoria de vida?

Você pode martelar um prego com uma chave inglesa, mas por quê? Você pode até usar uma furadeira se se esforçar bastante. Mas uma boa posse consciente do instrumento é precisamente o que distingue um profissional de um amador. E o profissional sabe que a principal característica da broca não está nisso. Então, por que você precisa conhecer padrões?

• Soluções comprovadas. Você gasta menos tempo usando soluções prontas em vez de reinventar a roda. Algumas decisões você pode pensar em si mesmo, mas muitas podem ser uma descoberta para você.
• Padronização de código. Você comete menos erros de cálculo ao projetar, usando soluções unificadas típicas, pois todos os problemas ocultos nelas foram encontrados há muito tempo.
• Dicionário de programação geral. Você diz o nome do padrão em vez de passar uma hora explicando a outros programadores que design legal você criou e quais classes são necessárias para isso.

Quais são os padrões?

Os padrões diferem no nível de complexidade, detalhe e cobertura do sistema que está sendo projetado. Fazendo uma analogia com a construção, você pode aumentar a segurança de um cruzamento colocando um semáforo ou pode substituir o cruzamento por um trevo inteiro de carros com passagens subterrâneas.

Os padrões mais simples e de baixo nível são expressões idiomáticas. Eles não são universais, pois são aplicáveis ​​apenas dentro da estrutura de uma linguagem de programação.

Os mais versáteis são os padrões de arquitetura que podem ser implementados em praticamente qualquer linguagem. Eles são necessários para projetar todo o programa, e não seus elementos individuais.

Mas o principal é que os padrões diferem em propósito. Os padrões que conheceremos podem ser divididos em três grupos principais:

• Os padrões de criação cuidam da criação flexível de objetos sem introduzir dependências desnecessárias no programa.
• Padrões estruturais mostram diferentes maneiras de construir relacionamentos entre objetos.
• Os padrões comportamentais cuidam da comunicação eficiente entre os objetos.

1.4 Introdução à UML

Vamos começar examinando os mesmos 23 padrões descritos no livro Gang of Four. Tanto os próprios padrões quanto seus nomes são coisas familiares, mesmo para um programador novato. Vou apresentá-los a você, mas recomendo fortemente a leitura desse mesmo livro sobre padrões.

Os padrões de design não estão vinculados a uma linguagem de programação específica, portanto, a UML geralmente é usada para descrevê-los. Foi muito popular há 20 anos, mas mesmo agora é usado às vezes. A propósito, a descrição dos padrões é apenas o local onde o uso da UML é o padrão.

Com UML, você pode descrever relacionamentos entre diferentes entidades. No nosso caso, são objetos e classes.

As relações entre as classes são descritas por quatro tipos de setas:

	composição (composição) - uma subespécie de agregação na qual "partes" não podem existir separadamente do "todo".
	agregação - descreve a relação "parte" - "todo", na qual a "parte" pode existir separadamente do "todo". O losango é indicado do lado “inteiro”.
	dependência - uma mudança em uma entidade (independente) pode afetar o estado ou comportamento de outra entidade (dependente). Uma entidade independente é indicada ao lado da seta.
	generalização - a relação de herança ou implementação de uma interface. Ao lado da seta está a superclasse ou interface.

Na verdade, tudo é muito simples aqui. A última seta na verdade significa que uma classe é herdada de outra classe. E a primeira e a segunda setas indicam que um objeto armazena um link para o segundo objeto. E é tudo.

Se o losango do link for preto, o link é fraco: os objetos podem existir uns sem os outros. Se o losango for branco, então os objetos estão fortemente relacionados, como uma classe HttpRequeste sua classe filha HttpRequest.Builder.

1.5 Lista de padrões

Os tipos de padrões serão indicados por cores e letras diferentes:

B- comportamental (comportamental);

C- gerador (criativo);

S- estrutural (estrutural).

E, finalmente, uma lista de 23 padrões de design: