[CLPE] Design patterns com c#

1,773 views
1,676 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,773
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
37
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Escopo especifica se o padrão é aplicado ao objeto ou a classe. - classe: foca na relação de herança, fixos em tempo de compilação - objeto: foca na interação entre objetos, podendo ser mudados em tempo de execução Creational patterns abstract the object instantiation process: They hide how objects are created and help make the overall system independent of how its objects are created and composed. Structural design patterns are design patterns that ease the design by identifying a simple way to realize relationships between entities.
  • [CLPE] Design patterns com c#

    1. 1. Design Patterns com C# Fernando Kakimoto [email_address] www.twitter.com/nandokakimoto
    2. 2. Quem Sou Eu? <ul><li>Centro de Informática - U.F.P.E. </li></ul><ul><ul><li>Graduado em Ciências da Computação (2008) </li></ul></ul><ul><ul><li>Mestrando em Ciências da Computação </li></ul></ul><ul><li>Inove Informática </li></ul><ul><ul><li>Engenheiro de Software / Líder de Equipe </li></ul></ul><ul><li>Certificações </li></ul><ul><ul><li>MCP | MCTS Web 2.0 </li></ul></ul><ul><ul><li>SCJP 6.0 </li></ul></ul><ul><li>Intereseses </li></ul><ul><ul><li>Arquitetura, metodologias ágeis, desenvolvimento Web </li></ul></ul>
    3. 3. Agenda <ul><li>Introdução </li></ul><ul><li>Classificação </li></ul><ul><li>Alguns padrões </li></ul><ul><li>Princípios SOLID </li></ul><ul><li>Anti-patterns </li></ul>
    4. 4. Introdução <ul><li>“ How can you distribute responsibility for design through all levels of a large hierarchy, while still maintaining consistency and harmony of overall design?” </li></ul>
    5. 5. Introdução <ul><li>Alexander sugeriu usar Padrões de Projeto </li></ul><ul><ul><li>Dicionário de termos relacionados a decisões básicas de projeto arquitetural </li></ul></ul><ul><li>Cada padrão descreve um problema comum do dia a dia e sua solução </li></ul><ul><ul><li>A solução pode ser reusada </li></ul></ul><ul><li>Discussões arquiteturais passaram a ser conduzidas por essa linguagem </li></ul>
    6. 6. Introdução <ul><li>[GoF] Design Patterns: Elements of Reusable Object-Oriented Software </li></ul>
    7. 7. Introdução <ul><li>“ 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 .” </li></ul><ul><li>- Gang of Four (Gamma et al.) </li></ul>
    8. 8. Por que padrões? <ul><li>Procurar objetos apropriados </li></ul><ul><li>Determinar granularidade dos objetos </li></ul><ul><li>Estimular reuso </li></ul><ul><li>Projetar mudanças </li></ul>
    9. 9. Nomenclatura <ul><li>Nome </li></ul><ul><ul><li>Contrução de um vocabulário </li></ul></ul><ul><li>Problema </li></ul><ul><ul><li>Quando aplicar o padrão </li></ul></ul><ul><li>Solução </li></ul><ul><ul><li>Estrutura genérica de elementos </li></ul></ul><ul><li>Consequências </li></ul><ul><ul><li>Trade-offs da implementação </li></ul></ul>
    10. 10. Classificação Propósito Criacional Estrutural Comportamental Escopo Classe Factory Method Adapter (class) Interpreter Template Method Objeto Abstract Factory Builder Prototype Singleton Adapter (object) Bridge Composite Decorator Facade Flyweight Proxy Chain of Responsability Command Iterator Mediator Memento Observer State Strategy Visitor
    11. 11. Factory Method Intençã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
    12. 12. Factory Method <ul><li>Estrutura </li></ul>
    13. 13. Factory Method <ul><li>Exemplo </li></ul>
    14. 14. Factory Method
    15. 15. Factory Method <ul><li>public interface Manipulator </li></ul><ul><li>{ </li></ul><ul><li>void DownClick(); </li></ul><ul><li>void Drag(); </li></ul><ul><li>void UpClick(); </li></ul><ul><li>} </li></ul>public class LineManipulator : Manipulator { public void DownClick() { Console. WriteLine( &quot;Line DownClick()&quot; ); } public void Drag() { Console. WriteLine( &quot;Line Drag()&quot; ); } public void UpClick() { Console. WriteLine( &quot;Line UpClick()&quot; ); } } public class TextManipulator : Manipulator { public void DownClick() { Console. WriteLine( “Text DownClick()&quot; ); } public void Drag() { Console. WriteLine( “Text Drag()&quot; ); } public void UpClick() { Console. WriteLine( “Text UpClick()&quot; ); } }
    16. 16. Factory Method <ul><li>public abstract class Figure </li></ul><ul><li>{ </li></ul><ul><li>public Manipulator Manipulator { get; set; } </li></ul><ul><li>public Figure() </li></ul><ul><li>{ </li></ul><ul><li>CreateManipulator(); </li></ul><ul><li>} </li></ul><ul><li>public abstract void CreateManipulator(); </li></ul><ul><li>public void DoSomething() </li></ul><ul><li>{ </li></ul><ul><li>this .Manipulator.Drag(); </li></ul><ul><li>} </li></ul><ul><li>} </li></ul>public class LineFigure : Figure { public override void CreateManipulator() { this. Manipulator = new LineManipulator (); } } public class TextFigure : Figure { public override void CreateManipulator() { this .Manipulator = new TextManipulator (); } }
    17. 17. Factory Method class Program { static void Main( string [ ] args) { Figure figure = new LineFigure (); figure.DoSomething(); figure = new TextFigure (); figure.DoSomething(); } }
    18. 18. Decorator Intençã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
    19. 19. <ul><li>Estrutura </li></ul>Decorator
    20. 20. Decorator <ul><li>Exemplo </li></ul>
    21. 21. Decorator
    22. 22. Decorator public abstract class LibraryItem { public int NumCopies { get; set; } public abstract void Display(); } public class Book : LibraryItem { private string Author; private string Title; public Book( string author , string title , int numCopies) { this. Author = author; this. Title = title; this. NumCopies = numCopies; } public override void Display() { Console. WriteLine( &quot; *** Book ***&quot; ); Console. WriteLine( &quot;Author: {0}&quot; , Author); Console. WriteLine( &quot;Title: {0}&quot; , Title); Console. WriteLine( &quot;#Copies: {0}&quot; , NumCopies); } }
    23. 23. Decorator public class Decorator : LibraryItem { protected LibraryItem LibraryItem { get; set; } public Decorator( LibraryItem libraryItem) { this. LibraryItem = libraryItem; } public override void Display() { LibraryItem.Display(); } } public abstract class LibraryItem { public int NumCopies { get; set; } public abstract void Display(); }
    24. 24. Decorator class Program { static void Main( string [ ] args) { Book book = new Book( &quot;Worley&quot;, &quot;Inside ASP.NET&quot; , 10); book.Display(); Borrowable borrowBook = new Borrowable (book); borrowBook.BorrowItem( &quot;Customer #1&quot; ); borrowBook.BorrowItem( &quot;Customer #2&quot; ); borrowBook.Display(); } } public class Borrowable : Decorator { public List < string > Borrowers { get ; private set ; } public Borrowable ( LibraryItem libraryItem ) : base (libraryItem) { this .Borrowers = new List < string >(); } public void BorrowItem( string name) { Borrowers.Add(name); this .LibraryItem.NumCopies- -; } public override void Display() { base. Display(); Borrowers.ForEach( b => Console.WriteLine ( &quot;borrower: {0}&quot; , b)); } }
    25. 25. Observer Intençã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
    26. 26. Observer <ul><li>Estrutura </li></ul>
    27. 27. Observer <ul><li>Exemplo </li></ul>
    28. 28. Observer
    29. 29. Observer public abstract class Subject <T> { private List < Observer <T>> Observers; public Subject() { this .Observers = new List < Observer <T>>(); } public void Attach( Observer <T> o) { this .Observers.Add(o); } public void Detach( Observer <T> o) { this .Observers.Remove(o); } public void Notify(T data) { this .Observers.ForEach(o => o.Update(data)); } } public class ClockTimer : Subject < DateTime > { public DateTime CurrentTime { get; set; } public ClockTimer( DateTime time) { this. CurrentTime = time; } public void Tick() { this. CurrentTime = DateTime .Now; this .Notify( this .CurrentTime); } }
    30. 30. Observer public interface Observer <T> { void Update(T data); } public class AnalogicTimer : Observer < DateTime > { public void Update( DateTime time) { Console .WriteLine( &quot;AnalogicTimer {0}&quot; , time); } } public class DigitalTimer : Observer < DateTime > { public void Update( DateTime time) { Console .WriteLine( &quot;DigitalTimer {0}&quot; , time); } }
    31. 31. Observer class Program { static void Main( string [ ] args) { ClockTimer timer = new ClockTimer ( DateTime .Now); AnalogicTimer analogicTimer = new AnalogicTimer (); timer.Attach(analogicTimer); DigitalTimer digitalTimer = new DigitalTimer (); timer.Attach(digitalTimer); timer.Tick(); timer.Detach(analogicTimer); Thread .Sleep(5000); timer.Tick(); } }
    32. 32. Strategy Intençã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
    33. 33. Strategy <ul><li>Estrutura </li></ul>
    34. 34. Strategy <ul><li>Exemplo </li></ul>
    35. 35. Strategy
    36. 36. Strategy public interface PersistenceStrategy <T> { void Save(T item); void Remove(T item); bool Exists(T item); } public class CollectionPersistence <T> : PersistenceStrategy <T> { public void Save(T item) { Console. WriteLine( &quot;CollectionPersistence: Save&quot; ); } public void Remove(T item) { Console .WriteLine( &quot;CollectionPersistence: Remove&quot; ); } public bool Exists(T item) { Console .WriteLine( &quot;CollectionPersistence: Exists&quot; ); return false; } }
    37. 37. Strategy class Program { static void Main( string [ ] args) { Contact c = new Contact() { Name = &quot;Fernando Kakimoto&quot;, PhoneNumer = &quot;(81)9162-2997&quot;, Email = &quot;nandokakimoto@gmail.com&quot; }; PersistenceStrategy < Contact > persistence = new CollectionPersistence < Contact >(); persistence.Save(c); persistence.Remove(c); persistence.Exists(c); persistence = new DataBasePersistence < Contact >(); persistence.Save(c); persistence.Remove(c); persistence.Exists(c); } } public class DataBasePersistence <T> : PersistenceStrategy <T> { public void Save(T item) { Console .WriteLine( &quot;DataBasePersistence: Save&quot; ); } public void Remove(T item) { Console .WriteLine( &quot;DataBasePersistence: Remove&quot; ); } public bool Exists(T item) { Console .WriteLine( &quot;DataBasePersistence: Exists&quot; ); return false; } }
    38. 38. SOLID Principles <ul><li>Expõe aspectos de gestão de dependência no desenvolvimento orientado à objetos </li></ul><ul><ul><li>Identifica código frágil e difícil de mudar/estender </li></ul></ul><ul><ul><li>Base para as –ilities desejadas por desenvolvedores </li></ul></ul><ul><li>Março de 1995, Robert C. Martin </li></ul>
    39. 39. SOLID Principles <ul><li>S ingle Responsability Principle </li></ul><ul><li>O pen-Closed Principle </li></ul><ul><li>L iskov Substituition Principle </li></ul><ul><li>I nterface Segregation Principle </li></ul><ul><li>D ependency Inversion Principle </li></ul>
    40. 40. Single Responsability Principle <ul><li>Uma classe deve ter uma única razão para mudar </li></ul><ul><li>Uma responsabilidade é um eixo de mudança </li></ul><ul><li>O que considerar como responsabilidade? </li></ul>
    41. 41. Open-Closed Principle <ul><li>Entidades de software devem ser abertas para extensões e fechadas para modificações </li></ul><ul><li>Uma mudança deve ser concentrada, sem afetar demais módulos do sistema </li></ul>
    42. 42. Liskov Substituition Principle <ul><li>Subclasses devem ser substituíveis por sua classe mãe </li></ul><ul><li>Simples caso de violação do princípio </li></ul><ul><li>Quadrado x Retângulo </li></ul>
    43. 43. Interface Segregation Principle <ul><li>Clientes não podem ser forçados a dependerem de interfaces que não usam </li></ul><ul><li>Interfaces pequenas e especícias para clientes </li></ul>
    44. 44. Dependency Inversion Principle <ul><li>Dependa de abstrações, não de concreções </li></ul><ul><li>Favorece OCP </li></ul>
    45. 45. Anti-Patterns <ul><li>Um padrão que aponta como sair </li></ul><ul><ul><li>De um problema para uma solução ruim </li></ul></ul><ul><ul><li>De uma solução ruim para uma solução boa </li></ul></ul><ul><li>Incentivados pela popularidade de Padrões de Projeto </li></ul><ul><li>1996, Michael Ackoyd - &quot; AntiPatterns: Vaccinations Against Object Misuse &quot; </li></ul>
    46. 46. Anti-Patterns <ul><li>The Big Ball of Mud </li></ul><ul><ul><li>Sistema sem arquitetura definida </li></ul></ul><ul><li>Overuse of Patterns </li></ul><ul><ul><li>Uso de Design Patterns sem necessidade </li></ul></ul><ul><li>God Objects </li></ul><ul><ul><li>Concentrar muitas responsabilidades à uma única classe </li></ul></ul><ul><li>Polter Geist </li></ul><ul><ul><li>Objetos usados apenas para passar informação </li></ul></ul>
    47. 47. Anti-Patterns <ul><li>Geographically Distributed Development </li></ul><ul><ul><li>Integrantes de uma equipe geograficamente separados grande parte do tempo </li></ul></ul><ul><li>Accidental Complexity </li></ul><ul><ul><li>Introduzir complexidade desnecessária à solução </li></ul></ul><ul><li>Walking Through a Mine Field </li></ul><ul><ul><li>Incerteza sobre o comportamento de um componente </li></ul></ul><ul><li>Copy and Paste Programming </li></ul><ul><ul><li>Copiar código existente ao invés de criar soluções genéricas </li></ul></ul>
    48. 48. Perguntas
    49. 49. Design Patterns com C# Fernando Kakimoto [email_address] www.twitter.com/nandokakimoto

    ×