[clpe] design patterns com c#
TRANSCRIPT
Quem Sou Eu? Centro de Informática - U.F.P.E.
Graduado em Ciências da Computação (2008) Mestrando em Ciências da Computação
Inove Informática Engenheiro de Software / Líder de Equipe
Certificações MCP | MCTS Web 2.0 SCJP 6.0
Intereseses Arquitetura, metodologias ágeis, desenvolvimento
Web
Agenda Introdução Classificação Alguns padrões Princípios SOLID Anti-patterns
Introdução
“How can you distribute responsibility for design through all levels of a large hierarchy, while
still maintaining consistency and
harmony of overall design?”
Introdução Alexander sugeriu usar Padrões de Projeto
Dicionário de termos relacionados a decisões básicas de projeto arquitetural
Cada padrão descreve um problema comum do dia a dia e sua solução A solução pode ser reusada
Discussões arquiteturais passaram a ser conduzidas por essa linguagem
Introdução [GoF] Design Patterns: Elements of Reusable
Object-Oriented Software
Introdução“A design pattern names, abstracts, and
identifies the key aspects of a common design structure that make it useful for creating a
reusable object-oriented design.”
- Gang of Four (Gamma et al.)
Por que padrões? Procurar objetos apropriados Determinar granularidade dos objetos Estimular reuso Projetar mudanças
Nomenclatura Nome
Contrução de um vocabulário Problema
Quando aplicar o padrão Solução
Estrutura genérica de elementos Consequências
Trade-offs da implementação
Classificação
Propósito
Criacional Estrutural Comportamental
Escopo
Classe
Factory Method
Adapter (class) InterpreterTemplate Method
Objeto
Abstract FactoryBuilderPrototypeSingleton
Adapter (object)BridgeCompositeDecoratorFacadeFlyweightProxy
Chain of ResponsabilityCommandIteratorMediatorMementoObserverStateStrategyVisitor
Factory MethodIntenção Motivação Consequências
Fornece uma interface para criação de famílias de objetos, sem especificar suas classes concretas
A classe não pode antecipar o objeto que ela deve criar
A classe precisa que a subclasse especifique o objeto criado
Programação para interfaces
Necessidade de subclasses Creator para criação de Products específicos
Factory Method Estrutura
Factory Method Exemplo
Factory Method
DecoratorIntenção Motivação Consequências
Adiciona responsabilidades dinamicamente a um objeto
Adicionar responsabilidades a objetos ao invés de classes
Responsabilidades podem ser retiradas
Quando extensão por herança é impraticável
Mais flexibilidade do que heranças estáticas
Evita explosão de classes
Inúmeros objetos semelhantes
Estrutura
Decorator
Decorator Exemplo
Decorator
ObserverIntenção Motivação Consequências
Define dependências entre objetos, tal que quando um objeto muda de estado, seus dependentes são notificados e atualizados
Manter consistência entre objetos relacionados
Manter baixo acoplamento
Um objeto deve notificar outro objeto sem fazer suposições prévias
Acoplamento abstrato entre Subject e Observer
Suporte para comunicação broadcast
Atualizações inesperadas
Observer Estrutura
Observer Exemplo
Observer
StrategyIntenção Motivação Consequências
Define uma família de algoritmos, encapsula cada um, e os torna substituíveis.
Configurar uma classe com um entre vários comportamentos
Diferentes variação para um mesmo algoritmo
Encapsula detalhes de implementação de um algoritmo
Define um comportamento para contextos de reuso
Alternativa a extensão de classes
Elimina instruções condicionais
Strategy Estrutura
Strategy Exemplo
Strategy
SOLID Principles Expõe aspectos de gestão de dependência
no desenvolvimento orientado à objetos Identifica código frágil e difícil de mudar/estender Base para as –ilities desejadas por
desenvolvedores Março de 1995, Robert C. Martin
SOLID PrinciplesSingle Responsability Principle
Open-Closed Principle
Liskov Substituition Principle
Interface Segregation Principle
Dependency Inversion Principle
Single Responsability Principle Uma classe deve ter uma única razão para
mudar Uma responsabilidade é um eixo de mudança O que considerar como responsabilidade?
Open-Closed Principle Entidades de software devem ser abertas para
extensões e fechadas para modificações Uma mudança deve ser concentrada, sem
afetar demais módulos do sistema
Liskov Substituition Principle Subclasses devem ser substituíveis por sua
classe mãe Simples caso de violação do princípio
Quadrado x Retângulo
Interface Segregation Principle Clientes não podem ser forçados a
dependerem de interfaces que não usam Interfaces pequenas e especícias para clientes
Dependency Inversion Principle Dependa de abstrações, não de concreções Favorece OCP
Anti-Patterns Um padrão que aponta como sair
De um problema para uma solução ruim De uma solução ruim para uma solução boa
Incentivados pela popularidade de Padrões de Projeto
1996, Michael Ackoyd - "AntiPatterns: Vaccinations Against Object Misuse"
Anti-Patterns The Big Ball of Mud
Sistema sem arquitetura definida Overuse of Patterns
Uso de Design Patterns sem necessidade God Objects
Concentrar muitas responsabilidades à uma única classe
Polter Geist Objetos usados apenas para passar informação
Anti-Patterns Geographically Distributed Development
Integrantes de uma equipe geograficamente separados grande parte do tempo
Accidental Complexity Introduzir complexidade desnecessária à solução
Walking Through a Mine Field Incerteza sobre o comportamento de um
componente Copy and Paste Programming
Copiar código existente ao invés de criar soluções genéricas
Perguntas