Fichas
DEV - GRASP
Fichas del conjunto (24)
- 1GRASP8General Responsability Assignment Software Pattern
- 2Objetivo do GRASPVisa comunicar detalhadamente os princípios e raciocínios necessários para a construção de projetos de comunicação entre objetos.
- 3Tipos de ResponsabilidadeSABER e FAZER
- 4SABER- Conhecimento sobre dados privados encapsulados.
- Conhecer os objetos relacionados.
- Conhecer coisas que se pode calcular ou derivar.
etc - 5FAZERFazer algo como:
criar um objeto, fazer um cálculo, iniciar uma ação, controlar ou coordenar algo em outro objeto. - 6Especialista na InformaçãoA Responsabilidade deve ser atribuída à classe que possui a informação necessária para satisfazê-la.
- 7Contra-indicação: EspecialistaEx: O Especialista diz que uma classe deveria ser responsável por salvar a sí mesma no banco, entretanto, isso fere os princípios de acoplamento, coesão e duplicação de cód.
- 8CriadorA classe B deve criar uma instancia de A, se:
B agrega A; B contém objetos de A; B registra A; B usa de maneira muito proxima A; B tem as informações iniciais de A; B é um criador de A - 9Contra-indicação: CriadorSe o objeto a ser criado for demasiadamente complexo e necessitar de muitas informações externas: Preferir uma "Fábrica"
- 10ControladorÉ um tratador e eventos de sistema. Funciona como uma fachada da UI para a camada de domínio.
Garante que as regras de negócio não sejam tratadas na camada de interface gráfica - 11Controlador: Regras-Deve representar o sistema como um todo (caso tenha poucas funcionalidades).
ou
- Representa um tratador de eventos por caso de uso (caso tenha muitas funcionalidades). - 12Controlador: OBSO Controlador não é um objeto de domínio, ele é uma criação artificial para tratar eventos do sistema.
(GRASP: Invenção Pura) - 13AcoplamentoÉ a medida do quão fortemente um elemento de software: tem conhecimento de, está associado a, depende de, outros elementos de software.
- 14Acoplamento: CorolárioO acoplamento em si, não é o problema. O problema está no acoplamento entre objetos instáveis e não pode ser considerado isoladamente dos outros princípios.
- 15CoesãoMede o quão fortemente as responsabilidades de um elemento de software estão relacionadas.
- 16Coesão: AnalogiaPessoas que assumem muitas responsabilidades, principalmente quando essas responsabilidades deveriam ser delegadas a outras pessoas.
- 17PolimorfismoQuando alternativas ou comportamentos variam segundo o tipo, deve-se atribuir a responsabilidade pelo comportamento. Cada classe para o comportamento o qual varia.
- 18Polimorfismo: Contra-indicaçãoUtilizar somente quando a variação no comportamento dos componentes for iminente. Existem áreas cujo a variação no comportamento é possível porém jamais surgirá.
- 19Invenção puraAtribuir um conjunto de responsabilidades coesas para uma classe artificial que não representa um objeto do domínio. Apoiando o fraco acoplamento, alta coesão e reutilização de cód.
- 20Invenção pura: Quando usarUsar quando os princípios do Especialista/Criador não fornecerem soluções adequadas.
Ex: Segundo o 'Especialista' uma classe deveria ser responsável por salvar a si própria no banco. Uma "invenção pura" 'DAO' melhora essa decisão. - 21IndireçãoAtribuir a responsabilidade a um objeto intermediário para funcionar como mediador, eliminando o acoplamento direto.
- 22Indireção: OBSInvenção pura, GOF: Adapter, Open Closed Principle, Controlador, Encapsulamento, são exemplos de Indireção.
- 23Variações ProtegidasIdentificar pontos de variação ou instabilidade e atribuir as responsabilidades de modo a criar uma interface estável em torno deles.
- 24Variações protegidas: ExUma interface ICalcImpostos com diferentes classes concretas implementando essa interface, fornece uma interface estável, ocultando as variações.
Información
- Descripción
- Superior Arq/Dev de Software Flashcards on GRASP, created by Carlos Lopes on 23/12/2015.
- Creado por
- Carlos Lopes
- Visitas
- 6
- Valoración