Princípios de Projeto

Princípios de Projeto

Começar. É Gratuito
ou inscrever-se com seu endereço de e-mail
Princípios de Projeto por Mind Map: Princípios de Projeto

1. Princípio da Responsabilidade Única

1.1. Toda classe deve ter uma única responsabilidade

1.2. Solução 1

1.2.1. Criar 2 classes

1.2.1.1. Classe de interface

1.2.1.2. Classe de "regra de negócio"

1.3. Essa solução permite reusar a classe de negócio com outras classe de interface

2. Princípio da Segregação de Interfaces

2.1. Responsabilidade Única com foco em interfaces

2.2. Define que as interfaces precisam ser

2.2.1. Pequenas

2.2.2. Coesas

2.2.3. Especificas para cada tipo de cliente

2.3. Objetivo

2.3.1. Evitar que clientes dependam de interfaces com métodos que não utilizam

2.4. Solução

2.4.1. Criar interfaces específicas

2.4.1.1. Exemplo

2.4.1.1.1. (FuncionarioCLT e FuncionarioPublico) que estendem a interface genérica (Funcionario).

3. Princípio de Inversão de Dependências

3.1. Recomendação

3.1.1. Uma classe cliente deve estabelecer dependências prioritariamente com abstrações e não com implementações concretas, pois abstrações (isto é, interfaces) são mais estáveis do que implementações concretas (isto é, classes)

3.1.2. A ideia é trocar (ou inverter) as dependências: em vez de depender de classes concretas, clientes devem depender de interfaces. Portanto, um nome mais intuitivo para o princípio seria Prefira Interfaces a Classes.

3.2. Exemplo

3.2.1. Pacote de estruturas de dados que oferece uma interface List e algumas implementações concretas (classes) para ela, como ArrayList, LinkedList e Vector

3.2.1.1. Sempre que possível, em código cliente desse pacote, declare variáveis, parâmetros ou atributos usando o tipo List

3.2.1.1.1. assim você estará criando código compatível com as diversas implementações concretas dessa interface

4. Princípio Aberto/Fechado

4.1. Proposto por

4.1.1. Bertrand Meyer

4.2. Objetivo

4.2.1. Uma classe deve estar fechada para modificações e aberta para extensões

4.2.2. O projeto da classe prevê a possibilidade de extensões e customizações

4.2.2.1. Para isso, o projetista pode se valer de recursos como herança, funções de mais alta ordem (ou funções lambda) e padrões de projeto, como Abstract Factory, Template Method e Strategy

4.2.3. Construção de classes flexíveis e extensíveis, capazes de se adaptarem a diversos cenários de uso, sem modificações no seu código fonte.

4.3. Requer que

4.3.1. O projetista de uma classe antecipe os seus pontos de extensão

4.3.1.1. Por isso, não é possível a uma classe acomodar todos os possíveis tipos de extensões que podem aparecer

4.3.1.1.1. Mas apenas aqueles para os quais são oferecidos pontos de extensão, seja via herança, funções de mais alta ordem ou padrões de projeto

4.4. Exemplo

4.4.1. A implementação da classe Collections com um algoritmo de ordenação sendo ele uma versão do MergeSort

4.4.1.1. Porém, os clientes da classe não podem alterar e customizar esse algoritmo, tendo que se contentar com a implementação default que é oferecida

4.4.1.1.1. Logo, sob o critério de customização do algoritmo de ordenação, o método sort não atende ao Princípio Aberto/Fechado

5. Princípio de Substituição de Liskov

5.1. Origem do nome

5.1.1. O nome do princípio é uma referência a Barbara Liskov

5.1.1.1. Professora do MIT e ganhadora da edição de 2008 do Prêmio Turing

5.2. Objetivo

5.2.1. Regras para redefinição de métodos de classes base em classes filhas.

5.2.2. O Princípio de Substituição de Liskov determina as condições, semânticas e não sintáticas que as subclasses devem atender para que um programa funcione

5.3. Exemplo

5.3.1. Suponha que um cliente chame um método getPrimo(n) de um objeto p da classe NumeroPrimo. Suponha agora que o objeto p seja substituído por um objeto de uma subclasse de NumeroPrimo

5.3.1.1. O cliente vai passar a executar o método getPrimo(n) dessa subclasse. Porém, essa substituição de métodos não deve ter impacto no comportamento do cliente

5.3.1.1.1. Para tanto, todos os métodos getPrimo(n) das subclasses de NumeroPrimo devem realizar as mesmas tarefas que o método original, possivelmente de modo mais eficiente.