✍️ 🚁 🥙 O livro "Padrões de design orientado a objetos" 🐉 🥞 🚢

Olá, habrozhiteli! Mais de 25 anos se passaram desde a primeira impressão dos Design Patterns. Durante esse período, o livro do popular se transformou em um culto. Em todo o mundo, é recomendável lê-lo para qualquer pessoa que queira conectar a vida à tecnologia da informação e programação. O idioma "russo" usado pelo pessoal de TI mudou, muitos termos em inglês tornaram-se familiares, padrões entraram em nossas vidas.

Aqui está uma edição de aniversário com uma tradução atualizada do livro, que se tornou uma leitura obrigatória para cada programador. “Padrões de Design Orientado a Objetos” substituíram as “Técnicas de Design Orientado a Objetos”.

Quatro desenvolvedores de primeira classe - um grupo de quatro - chamam a atenção para a experiência do OOP na forma de 23 padrões. Os padrões apareceram porque os desenvolvedores estavam procurando maneiras de aumentar a flexibilidade e o grau de reutilização de seus programas. Os autores não apenas fornecem princípios para o uso de padrões de design, mas também sistematizam as informações. Você aprenderá sobre o papel dos padrões na arquitetura de sistemas complexos e poderá criar rápida e eficientemente seus próprios aplicativos, levando em consideração todas as restrições que surgem ao desenvolver grandes projetos. Todos os modelos são retirados de sistemas reais e baseados em práticas reais. O código C ++ ou Smalltalk é mostrado para cada padrão, demonstrando seus recursos.

Prefácio

O livro descreve soluções simples e elegantes para problemas típicos que surgem no design orientado a objetos.

Os padrões apareceram porque muitos desenvolvedores estavam procurando maneiras de aumentar a flexibilidade e o grau de reutilização de seus programas. As soluções encontradas são incorporadas de forma concisa e facilmente praticável. A Gangue dos Quatro explica cada padrão com um exemplo simples em uma linguagem clara e compreensível. O uso de padrões no desenvolvimento de sistemas de software permite ao designer ir para um nível mais alto de desenvolvimento do projeto. Agora, o arquiteto e o programador podem operar com nomes figurativos de padrões e se comunicar em um idioma.

Assim, o livro resolve dois problemas.

Primeiro, ele introduz o papel dos padrões na criação da arquitetura de sistemas complexos.

Em segundo lugar, permite que os designers desenvolvam facilmente seus próprios aplicativos usando os padrões contidos no manual.

O que mudou na edição de 2020?

A terminologia foi atualizada (por exemplo, o termo "refatoração" já criou raízes para a "reorganização" do código, para o compartilhamento que está "compartilhando" em vez de "separação" e para mixin é "mistura");
estilo atualizado;
palavras desnecessariamente volumosas foram eliminadas (por exemplo, "especificação" ou "instanciação". A primeira pode ser adequadamente substituída por "definição", a segunda por "criação de uma instância");
o livro é finalmente chamado de “Padrões de Design Orientado a Objetos”.

MÉTODO DE MODELO DE PADRÃO (MÉTODO DE MODELO)

O nome e a classificação do padrão O

método do modelo é o padrão do comportamento da classe.

Objetivo O

método de modelo define a base do algoritmo e permite que as subclasses redefinam algumas etapas do algoritmo sem alterar sua estrutura como um todo.

Motivação

Considere a estrutura do aplicativo, que possui as classes Aplicativo e Documento. A classe Application é responsável por abrir documentos existentes armazenados em um formato externo (por exemplo, em um arquivo). Um objeto da classe Document representa informações do documento após a leitura de um arquivo.

Os aplicativos criados com base nessa estrutura podem gerar subclasses das classes Application e Document que atendem a necessidades específicas.

Por exemplo, um editor gráfico define subclasses de DrawApplication e DrawDocument e uma planilha define subclasses de SpreadsheetApplication e SpreadsheetDocument.

A classe abstrata Application define um algoritmo para abrir e ler um documento na operação OpenDocument:

void Application::OpenDocument (const char* name) {
      if (!CanOpenDocument(name)) {
          //   
          return;
      }

      Document* doc = DoCreateDocument();

      if (doc) {
          _docs->AddDocument(doc);
          AboutToOpenDocument(doc);
          doc->Open();
          doc->DoRead();
      }
}

A operação OpenDocument define todas as etapas para abrir um documento. Ele verifica se é possível abrir o documento, cria um objeto da classe Document, o adiciona ao conjunto de documentos e lê o documento a partir do arquivo.

Uma operação no formato OpenDocument será chamada de método de modelo que descreve o algoritmo nas categorias de operações abstratas que são substituídas nas subclasses para obter o comportamento desejado. Subclasses da classe Application verificam se podem abrir (CanOpenDocument) e criar um documento (DoCreateDocument). Subclasses da classe Document leem o documento (DoRead). O método de modelo também define uma operação que permite que as subclasses de aplicativos obtenham informações de que um documento está prestes a ser aberto (AboutToOpenDocument).

Definindo algumas etapas do algoritmo usando operações abstratas, o método de modelo captura sua sequência, mas permite que elas sejam implementadas nas subclasses das classes Application e Document.

Aplicabilidade

Condições básicas para aplicar o método de modelo de padrão:

um único uso das partes invariantes do algoritmo, enquanto a implementação do comportamento de mudança permanece a critério das subclasses;
a necessidade de isolar e localizar em uma classe o comportamento comum a todas as subclasses para evitar duplicação de código. Este é um bom exemplo da técnica de "bracketing para generalizar" descrita por William Opdyke e Ralph Johnson [OJ93]. Primeiro, são reveladas diferenças no código existente, que são transferidas para operações separadas. Por fim, os diferentes fragmentos de código são substituídos pelo método de modelo do qual novas operações são chamadas;
gerenciamento de extensão de subclasse. O método do modelo pode ser definido para acionar ganchos - consulte a seção Resultados - em pontos específicos, permitindo a expansão apenas nesses pontos.

Estrutura

Participantes

AbstractClass (Application) - classe abstract:

define operações primitivas abstratas que são substituídas em subclasses específicas para implementar as etapas do algoritmo;
implementa um método de modelo que define o esqueleto de um algoritmo. O método de modelo chama operações primitivas, bem como operações definidas na classe AbstractClass ou em outros objetos;

ConcreteClass (MyApplication) - classe específica:

implementa operações primitivas que executam as etapas do algoritmo de uma maneira que depende da subclasse.

O relacionamento

ConcreteClass assume que as etapas invariantes do algoritmo serão executadas no AbstractClass.

Os

métodos de modelo de resultados são uma das técnicas fundamentais para reutilizar o código. Eles desempenham um papel particularmente importante nas bibliotecas de classes, pois fornecem a capacidade de criar um comportamento comum nas classes de bibliotecas.

Os métodos de modelo levam a uma estrutura de código invertida, que às vezes é chamada de princípio de Hollywood, implicando a frase "Não nos chame, nós o chamaremos", frequentemente usada neste império de filmes [Swe85]. Nesse caso, isso significa que a classe pai chama operações de subclasse e não vice-versa.

Os métodos de modelo chamam operações dos seguintes tipos:

operações específicas (da classe ConcreteClass ou das classes do cliente);
operações específicas da classe AbstractClass (ou seja, operações úteis para todas as subclasses);
operações primitivas (isto é, operações abstratas);
métodos de fábrica (veja padrão de método de fábrica (135));
operações de gancho que implementam um comportamento padrão que pode ser estendido nas subclasses. Freqüentemente, essa operação padrão não faz nada.

É importante que as operações do modelo distinguam claramente entre operações de gancho (que podem ser substituídas) e operações abstratas (que devem ser substituídas). Para reutilizar uma classe abstrata com a máxima eficiência, os autores das subclasses precisam entender quais operações devem ser substituídas.

Uma subclasse pode estender o comportamento de uma operação, substituindo-a e chamando explicitamente a operação da classe pai:

void DerivedClass::Operation () {
      //   DerivedClass
      ParentClass::Operation();
}

Infelizmente, é muito fácil esquecer a necessidade de chamar uma operação herdada. Essa operação pode ser transformada em um método padrão para fornecer ao pai o controle sobre como as subclasses a estendem. A idéia é chamar uma operação de gancho de um método de modelo na classe pai. As subclasses poderão redefinir exatamente esta operação:

void ParentClass::Operation () {
      //  ParentClass
      HookOperation();
}

Na classe pai ParentClass, a operação HookOperation não faz nada:

void ParentClass::HookOperation () { }

As subclasses substituem HookOperation para estender seu comportamento:

void DerivedClass::HookOperation () {
   //    
}

Implementação

Ao implementar um método de modelo de padrão, você deve prestar atenção aos seguintes aspectos:

C++. , , . , . , , . , -;
. , . , ;
convenção de nomes. Você pode destacar operações que precisam ser substituídas adicionando um prefixo aos seus nomes. Por exemplo, na estrutura MacApp para aplicativos Macintosh [App89], os nomes dos métodos de modelo começam com o prefixo Do: DoCreateDocument, DoRead e assim por diante.

Exemplo de código

O exemplo a seguir em C ++ mostra como uma classe pai pode impor uma invariável em suas subclasses. Um exemplo é retirado da biblioteca NeXT AppKit [Add94]. Considere a classe View, que suporta o desenho na tela, um tipo de invariante, que consiste no fato de que as subclasses podem alterar a vista apenas quando estiver em foco. Isso requer que um contexto de desenho específico seja definido (por exemplo, cores e fontes).

Você pode usar o método Display para definir o estado. A classe View define duas operações específicas (SetFocus e ResetFocus), que definem e redefinem respectivamente o contexto do desenho. A operação do gancho View da classe View faz o próprio desenho. O visor chama SetFocus antes de DoDisplay para preparar o contexto e ResetFocus após DoDisplay para redefini-lo:

void View::Display () {
      SetFocus();
      DoDisplay();
      ResetFocus();
}

Para oferecer suporte à invariável, os clientes da classe View sempre chamam as subclasses Display e View sempre substituem DoDisplay.

Na classe View, a operação DoDisplay não faz nada:

void View::DoDisplay () { }

As subclasses substituem-no para adicionar seu comportamento específico de desenho:

void MyView::DoDisplay () {
      //   
}

Os

métodos de modelo de aplicativos conhecidos são tão fundamentais que são encontrados em quase todas as classes abstratas. Rebecca Wirfs-Brock et al. [WBWW90, WBJ90] discutem métodos de modelo em detalhes.

Padrões relacionados Os

métodos de fábrica (135) são freqüentemente chamados de métodos padronizados. No exemplo da seção Motivação, o método de modelo OpenDocument chamado de método DoCreateDocument de fábrica.
Estratégia (362): os métodos de gabarito usam herança para modificar parte do algoritmo. As estratégias usam delegação para modificar o algoritmo como um todo.

»Mais informações sobre o livro podem ser encontradas no site da editora
» Sumário
» Trecho de

Khabrozhiteley cupom de 25% de desconto - OOP

Após o pagamento da versão impressa do livro, um livro eletrônico é enviado por e-mail.

O livro "Padrões de design orientado a objetos"

Prefácio

MÉTODO DE MODELO DE PADRÃO (MÉTODO DE MODELO)

More articles: