Object Oriented Design Patterns

Slides for the Code Slingers Object Oriented Design Patterns talk on 08/11/2016

Transcript

1. OBJECT ORIENTED DESIGN PATTERNS
2. UNIFIED MODELING LANGUAGE(UML) • Standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems
3. UML CLASS STRUCTURE 1 n
4. SYMPTOMS OF BAD ARCHITECTURE • Rigidity – Difficult to change • Fragility – Tendency to break in many places when 1 change is made • Immobility – An application contains parts that are useful to another system, but too risky to break out • Viscosity – Cases where the design of the software is hard to preserve. The hacky change is easier than the right change
5. SOLID PRINCIPLES • Single Responsibility Principle • Open/Closed Principle • Liskov Substitution Principle • Interface Segregation Principle • Dependency Inversion Principle
6. WHAT? WHY? • Common vocabulary to talk about different structures of code • Can be used in any OO language • Easily recognizable code structures even to someone with no knowledge of the program
7. CATEGORIES • Creational • Structural • Behavioral
8. FAÇADE • Structural • Hides the complexity of an external system by providing simpler, easy to use methods to interact with the external system • Can reduce the number of dependencies in your code
9. FAÇADE
10. FAÇADE
11. WHERE COULD WE USE THIS? • Combining many related many things into 1 interface • Making a horrible API easier to use
12. PROXY • Structural • Provide a surrogate or placeholder for another object to control access to it
13. PROXY
14. PROXY
15. WHERE COULD WE USE THIS? • Controlling access to “expensive to create” objects
16. ADAPTER • Structural • A single class designed to join functionalities of independent or incompatible interfaces
17. ADAPTER
18. ADAPTER
19. WHERE COULD WE USE THIS? • Going from one stack to another • Separating legacy code from shiny new code
20. STRATEGY • Behavioral • Defines a family of algorithms, encapsulates each one, and makes them interchangeable. • Improves readability by isolating behavior
21. STRATEGY
22. STRATEGY
23. WHERE COULD WE USE THIS? • Anything where extensibility is desired • You need behavior to be decided at runtime • Validating data based on type, source, etc
24. DECORATOR • Structural • Adds new functionality to an existing object without altering its structure
25. DECORATOR
26. DECORATOR
27. WHERE COULD WE USE THIS? • Anywhere you want to add behavior at runtime
28. OBSERVER • Behavioral • Defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically
29. OBSERVER
30. OBSERVER
31. OBSERVER
32. WHERE COULD WE USE THIS? • Anywhere you want to react to changes to something • Eventing systems • Knockout.js observables • MVC Views
33. ITERATOR • Behavioral • A way to access elements of a collection object in a sequential manner without any need to know it’s underlying representation
34. ITERATOR
35. ITERATOR
36. WHERE COULD WE USE THIS? • Anytime you’re using arrays, iterators, ienumerables, etc
37. STATE • Behavioral • A way to change class behavior based on its state • State Machines
38. STATE
39. STATE
40. WHERE COULD WE USE THIS? • Long running workflows • Game opponent AI
41. FACTORY • Creational • Define an interface for creating an object, but let subclasses decide which class to instantiate
42. FACTORY
43. FACTORY
44. WHERE COULD WE USE THIS? • Modular systems
45. ABSTRACT FACTORY • Creational • Factory of factories • Provides an interface which is responsible for creating a factory of related objects without explicitly specifying their classes
46. ABSTRACT FACTORY
47. ABSTRACT FACTORY
48. WHERE COULD WE USE THIS?
49. TEMPLATE • Behavioral • Abstract class exposing defined ways(templates) to execute its methods. Subclasses can override behavior if necessary, but are invoked the same way
50. TEMPLATE
51. TEMPLATE
52. WHERE COULD WE USE THIS? • Sharing a common interface between classes
53. COMPOSITE • Structural • Used when you need to treat a group of objects in a similar way as a single object • Usually composed as part of a tree structure
54. COMPOSITE
55. WHERE COULD WE USE THIS? • Folder Structure
56. SINGLETON • Creational • A class which is responsible for creating an object while making sure that only a single object gets created • Frequently misused
57. SINGLETON
58. SINGLETON
59. WHERE COULD WE USE THIS? • Many places need to access one thing
60. COMMAND • Behavioral • A request is wrapped under an object as a command and pass to an invoker object. The invoker object finds an object that can handle this command and passes it to that object. • Allows requests to be encapsulated as objects
61. COMMAND
62. COMMAND
63. WHERE COULD WE USE THIS? • UI Interactions
66. USEFUL RESOURCES • Head First Design Patterns • Design Patterns: Elements of Reusable Object-Oriented Software • http://www.dofactory.com/net/design-patterns - C# focused • http://www.tutorialspoint.com/design_pattern - Java focused • http://www.mcdonaldland.info/files/designpatterns/designpatternscard.pdf • https://sourcemaking.com/design_patterns
67. INTEREST IN ENTERPRISE INTEGRATION PATTERNS? • Messaging • Publish/Subscribe • Eventing