Design Patterns com C#

Fernando Kakimotonandokakimoto@gmail.com

www.twitter.com/nandokakimoto

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

Design Patterns com C#

Fernando Kakimotonandokakimoto@gmail.com

www.twitter.com/nandokakimoto