Começar. É Gratuito
ou inscrever-se com seu endereço de e-mail
Rocket clouds
GRASP por Mind Map: GRASP

1. Básicos

1.1. Especialista

1.1.1. Qual é o princípio mais básico pelo qual responsabilidades são atribuídas no POO ?

1.1.1.1. Atribuir responsabilidade para o especialista da informação

1.2. Criador

1.2.1. Quem deve ser responsável por criar uma nova instância de alguma classe?

1.2.1.1. Atribuir responsabilidade por criar uma nova instancia de uma classe

1.3. Coesão Alta

1.3.1. Como manter a complexidade (das classes) em um nível “controlável”? Isto é, Como gerenciar a complexidade?

1.3.1.1. Atribuir responsabilidade de modo que a coesão permaneça alta

1.4. Acoplamento fraco

1.4.1. Como conseguir menor dependência (entre as classes), o pequeno impacto à mudanças e aumentar a reutilização?

1.4.1.1. Atribuir a responsabilidade de modo que o acoplamento (dependência entre classes) permaneça baixo.

1.5. Controlador

1.5.1. Quem deve ser responsável por tratar um evento do sistema?

1.5.1.1. Atribuir responsabilidade de tratar um evento do sistema para um classe controladora

2. Avançados

2.1. Polimorfismo

2.1.1. • Como tratar alternativas com base no tipo? • Como criar componentes de software interligáveis (plugáveis)? • Deseja-se evitar variação condicional (if-then-else): pouco extensível. • Deseja-se substituir um componente por outro sem afetar o cliente.

2.1.1.1. Atribuir responsabilidade pelo comportamento aos tipos, para os que o comportamento variam

2.2. Invenção pura

2.2.1. Às vezes, durante o projeto é preciso atribuir responsabilidades que não são encaixam naturalmente em nenhuma das classes conceituais

2.2.2. Criar uma classe artificial que não representa nenhuma entidade do domínio para manter alta coesão, baixo acoplamento

2.3. Indireção

2.3.1. Onde colocar uma responsabilidade de modo a evitar o acoplamento direto entre duas ou mais classes? Como desacoplar objetos de modo a possibilitar o baixo acoplamento e manter alta a possibilidade de reuso?

2.3.1.1. Atribuir responsabilidade a um objeto intermediário que faça a mediação entre componentes ou serviços evitando acoplamento

2.4. Variáveis protegidas

2.4.1. Como projetar objetos, subsistemas e sistemas de modo que as variações ou instabilidades nesses elementos não tenham um impacto indesejável sobre outros elemento s

2.4.1.1. Evitar enviar mensagens para objetos muito distantes e identificar pontos de variações, atribuir responsabilidade criar uma interface estável