Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ICTA Technology Meetup 06 - Enterprise Application Design Patterns


Published on

Enterprise Application Design Patterns

ICTA Technology Meetup 06 - Enterprise Application Design Patterns

  1. 1. ICTA Technology Meetup 06 Enterprise Application Design Patterns (Part 01) By Crishantha Nanayakkara
  2. 2. Agenda Enterprise Design Patterns – An Introduction Enterprise Design Pattern Catalogs Gang Of Four (GOF) Patterns What Next? ­ Enterprise Application  Architecture Design Patterns 2
  3. 3. Design Patterns An Introduction 3
  4. 4. 4
  5. 5. ● “The gap between the best software engineering practice and the average practice is very wide – perhaps wider than the other engineering ” – Fred Brooks (A famous author, ACM award winner) 5
  6. 6. What is a Pattern? This means, a Design Pattern gives you a solution to a common recurring design problem However, The Design Patterns are not meant to be laws or rules; they are just guidelines that you can even alter to fit to your needs 6
  7. 7. How to create your own design pattern? ● ● Firstly, get the complete design pattern catalog and get familiar with them If you find a new pattern, then apply, The Rule of Three Pattern can be called a pattern if it has been applied in real world solution by at least three times 7
  8. 8. OO vs Design Patterns ● Knowing the OO basics (abstraction, encapsulation, inheritance, polymorphism) will not make you a good designer!!! Oh!!! What should  I do then? 8
  9. 9. OO vs Design Patterns ● ● ● Patterns show you how to build systems with good OO design qualities Patterns do not give you code. They give general solutions to design problems Patterns are not invented they are discovered 9
  10. 10. Are patterns always great? ● NO – Patterns are a tool, which only be used when it is needed – Heavy use of patterns will lead to complexity – Design patterns can be used as a shared vocabulary for communicating the design to others irrespective of the programming language 10
  11. 11. What are anti-patterns? ● If a design pattern gives you a general solution to a recurring problem in a particular context then what does an anti-pattern give u? – ● An anti-pattern tells you how to go from a problem to a BAD solution Why worry about finding anti-patterns? – To prevent other developers from making the same mistake 11
  12. 12. (Reference: 12
  13. 13. Enterprise Design  Pattern Catalogs 13
  14. 14. GOF Design Patterns Enterprise Application Architecture Design Patterns  Enterprise Integration Design Patterns  SOA Patterns Security Patterns Cloud Patterns 14
  15. 15. What are Pattern Catalogs? The much formal way of specifying pattern descriptions The first and the most definite Fundamental Design Pattern Catalog is GOF (There are 23 fundamental patterns in it!!) Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1995) 15
  16. 16. Gang of Four (GOF) Design Patterns Catalog 16
  17. 17. Enterprise Application Architecture Patterns Catalog ( 17
  18. 18. Enterprise Intergration Patterns Catalog 18
  19. 19. GOF Design Patterns An Introduction 19
  20. 20. 20
  21. 21. Behavioural Patterns 21
  22. 22. GOF Design Pattern Organization 22
  23. 23. GOF Design Pattern Relationships 23
  24. 24. Strategy Pattern ● Design Principle 1 Identify the aspects of your application that vary and separate them from what stays the same ● Design Principle 2 Program to an interface not to an implementation ● Design Principle 3 Favor composition over inheritance 24
  25. 25. Strategy Pattern 25
  26. 26. Strategy Pattern 26
  27. 27. Strategy Pattern Reference: Head First Design Patterns 27
  28. 28. Reference: Head First Design Patterns 28
  29. 29. Reference: Head First Design Patterns 29
  30. 30. The Observer Pattern Observer 1 Observer 2 Subscribers Subject Publisher Observer 3 When the in Subject changes, subscribers are notified ●The observers are subscribed to the Subject to receive updates when the Subject data changes ● Unsubscribed 30
  31. 31. Command Pattern Concrete Command Objects Invoker Receiver 31
  32. 32. Creational Patterns 32
  33. 33. Singleton Pattern This overcomes the multiple threading issue. However, the synchronization is bit expensive This way is good if the performance is not an issue 33
  34. 34. The Simple Factory 34
  35. 35. The Simple Factory 35
  36. 36. Simple Factory 36
  37. 37. The Factory Method The factory method pattern encapsulates the object creation by letting subclasses to decide what objects to create 37
  38. 38. The Factory Method This is the “Factory Method” Factory objects are created through INHERITANCE 38
  39. 39. Dependency Inversion Principle This is all about reducing dependencies to concrete classes in our code ● Before Factory Method ● After Factory Method Abstract Class Concrete Classes Though this principle is quite similar to “Program to an interface” principle, this makes a bigger statement 39
  40. 40. Structural Patterns 40
  41. 41. Decorator Pattern 41
  42. 42. Decorator Pattern 42
  43. 43. Decorator Pattern Cannot Connect Can Connect 43
  44. 44. Decorator Pattern 44
  45. 45. Adapter vs Decorator Pattern ● Adapter Pattern “Adapter is used when you have an abstract interface, and you want to map that interface to another object, which has similar functional role, but a different interface” Basically it is used to Convert the interface of an object into something else 45
  46. 46. ● Decorator Pattern “Decorator is used to extend the functionality of an object while maintaining its own interface” Since both “Decorator” and “Adapter” patterns are used to “wrap” objects, they are basically known as “Wrapper Patterns” 46
  47. 47. Facade Pattern 47
  48. 48. Facade Pattern ● ● ● ● ● Facades don’t encapsulate the sub system classes They provide a simplified interface to their functionality The sub system classes still remain for direct access to outside clients One sub system can have any number of facades linked to it Decouples the client from a sub system – If you change any of the sub systems, your client code does not need to change. 48
  49. 49. Facade Pattern ● Design Principle The principle of least knowledge Talk only to your immediate friends This prevents us from creating a large number of classes coupled together. Having too many dependencies creates a fragile design 49
  50. 50. Proxy Pattern Remote Proxy ● There are different kinds of proxy types ● The above is called the “Remote Proxy” ● The “Remote Proxy” acts as a local representative for an remote object. A method call on an “Remote Proxy” results the call being transferred on the wire and the result is returned back to the proxy and to the client 50
  51. 51. Local heap Client object Proxy object Remote heap Remote call Remote object The “client object” acts like its making remote calls. ● The “proxy object” pretends to be like the “remote object” ● Actually what happens is, the “client object” calls methods in the “proxy object” (in its local heap), which handles all low level details of communication ● 51
  52. 52. Composite Pattern Composites Leaf Nodes 52
  53. 53. Composite Pattern MenuComponent Menu MenuItem MenuItems 53
  54. 54. Composite Pattern All components must implement the MenuComponent interface; Why? In order for the composite to work transparently to the client, you must implement the same interface for all objects in the composite Sometimes, the best possible way is to throw Run-time Exceptions to all unrelated methods 54
  55. 55. The MenuComponent Menu Both Menu and MenuItem components should implement this interface Having default implementation will be difficult for each method MenuItem Hence, exceptions are thrown if any invalid method is called through a component Common 55
  56. 56. 56
  57. 57. 57