Grasp:

(Slide grasp-2.1)
● Princípio do Criador: um objeto B só cria um objeto A se:
○ B contém A, ou agrega de forma composta;
○ B usa A de maneira muito próxima;
○ B contém os dados iniciais de A;
● Especialista na informação: um objeto só vai ter responsabilidade X se ele tiver
informação necessária para satisfazê-la;
○ Manter nas responsabilidades do objeto apenas comportamentos relativos
aos dados conhecidos;
○ Delegar a outros objetos responsabilidades ligadas aos dados dos mesmos;
● Lei do Demérito(ligada ao especialista da informação): um método M de um objeto O
deve somente invocar métodos dos seguintes tipos de objetos:
○ Do próprio O;
○ Parâmetros de M;
○ Qualquer objeto instanciado dentro de M;
○ Variável global, acessível por O, no escopo de M;
● Separação Modelo-Visão:
○ Não acoplar objetos da interface do usuário com objetos do domínio;
○ Não atribuir a um objeto da interface do usuário responsabilidades do
domínio;
○ Objetos da interface do usuário apenas tratam eventos, coletam dados e
delegam solicitações à objetos do domínio;
● Controlador: atribuir a responsabilidade a um objeto que represente uma dessas
escolhas:
○ Um subsistema, sistema inteiro, ou um objeto raiz;
○ Um caso de uso que contenha a operação;
● Acoplamento baixo: atribuir responsabilidades favorecendo o acoplamento baixo:
○ Grau de relacionamento com outros objetos;
○ Avalie o acoplamento das possíveis soluções;
○ Avalie o acoplamento do código legado ao realizar manutenção ou evolução;
● Coesão alta: atribuir responsabilidades de modo que a coesão permaneça alta:
○ Avalie a coesão das possíveis soluções;
○ Avalie a coesão do código legado ao realizar manutenção ou evolução;
(Slide aula-coesão)
● Tipos de coesão:
○ Coincidente(PIOR): nenhuma correlação, apenas agrupamento de
responsabilidades;
○ Temporal(EVITAR): as responsabilidades são acionadas em períodos ou
frequências semelhantes;
○ Procedural(USAR COM MODERAÇÃO): as responsabilidades são acionadas
em ordem, mas não compartilham dados;
○ Comunicacional(USAR): as responsabilidades compartilham dados comuns
ou a mesma estrutura de dados;
 ○ Sequencial(USAR): as responsabilidades fornecem dados de saídas para as
demais, de forma sequencial;
○ Funcional(SUPRA SUMO): Módulos possuem responsabilidades muita bem
definidas e enxutas;
● Tipos de acoplamento:
○ Conteúdo(PIOR):
■ Módulo A conhece a estrutura interna do Módulo B;
■ Quebra do encapsulamento da informação;
○ Dados/recursos comuns concorrentes(EVITAR): dados globais não são uma
boa escolha;
○ Controle (USAR COM MODERAÇÃO): Módulo A usa mensagens para
controlar os dados/comportamento do Módulo B;
○ Estrutura de dados(USAR):
■ Módulo A passa uma estrutura de dados para o Módulo B, que
precisa apenas de uma parte;
■ Pode ocorrer impacto se a forma de acessar a parte (dentro da
estrutura completa) for alterada;
○ Parâmetros e Troca de Mensagens(SUPRA SUMO): Módulos A e B trocam
mensagens. Dados são passados por parâmetro, de preferência dados de
tipos básicos (primitivos ou built-in da linguagem);
(Slide grasp-2.2)
● Polimorfismo: Atribuir a responsabilidade aos tipos usando operações polimórficas:
○ Herança direta ou herança múltipla (interfaces);
● Recomendações no uso de herança:
○ Objeto da subclasse ‘é um tipo especial de’ e não um ‘papel assumido por’
○ Objeto da subclasse nunca tem que mudar para outra subclasse ou
hierarquia;
○ Subclasse estende a superclasse mas não faz override ou anulação das
variáveis e/ou métodos;
○ Não é uma subclasse de uma classe ‘utilitária’;
○ Para classes do domínio do problema, a subclasse expressa tipos especiais
de papéis, transações ou dispositivos/recursos;
● Projetando com interfaces:
○ Use interface para apoiar o polimorfismos sem se comprometer com uma
hierarquia de classes;
○ Superclasses carregam implementações, classes não;
● A implements B:
○ A se comporta como B;
○ A não herda nenhum comportamento prévio de B;
● A extends B:
○ A é um tipo especial de B;
○ A herda o comportamento e dados privados de B;
(Slide grasp-2.3)
● Indireção: Usar um mediador entre os componentes, para evitar o acoplamento
direto
○ A(cliente) → Mediador → B, C, D…(serviços);
○ O mediador cria uma indireção entre os componentes;
○ Protege o cliente do mediador de mudanças nos serviços;
 ○ Promove o reuso dos serviços, através do mediador
○ Facilita evolução dos serviços, sem impacto nos clientes
● Variações Protegidas: identificar pontos de variação previsíveis, e atribuir
responsabilidades criando interfaces em torno;
(Slide ppoo-3.1 e ppoo-3-2)
● Responsabilidade Única:
○ Responsabilidades são do tipo “Fazer” e/ou “Saber”;
○ Saber: uma informação pode mudar de formato ou ser desmembrada ou
expandida;
○ Fazer: uma nova forma de processar dados pode ser necessária;
● Separando responsabilidades (alguns exemplos):
○ Estrutura de dados com múltiplas entidades de negócio:
■ Solução: quebrar em agregações/composições;
○ Algoritmos distintos para mesma estrutura de dados:
■ Solução: separar algoritmos em classes distintas, atuando sobre
mesma classe de dados;
○ Algoritmos/comportamento complementar junto principal:
■ Solução: separar comportamento complementar em classe distinta e
estabelecer associação;
● Aberto-Fechado:
○ Aberto para extensão: Comportamento do módulo pode ser estendido com
novos comportamentos necessários para mudanças de requisitos;
○ Fechado para modificação: Estender comportamento não resulta em
mudanças no código atual do módulo;
○ Abstrações são planejadas, para que novos comportamentos sejam
incorporados através de novas classes derivadas;
● Usar interfaces:
○ Acoplamento com classe concreta (ruim):
■ Amarrado ao contrato e à implementação;
■ Difícil estender sem impacto;
○ Acoplamento com abstração (bom):
■ Amarrado apenas ao contrato da classe abstrata ou interface;
■ Fácil inserir novas implementações;
● Substituição de Liskov:
○ Subtipos devem ser substitutos para seus tipos base;
○ Abstração e polimorfismo: Base da gestão de dependências;