Enterprise Application Design Patterns

1. ICTA Technology Meetup 06
Enterprise Application
Design Patterns
(Part 01)
By Crishantha Nanayakkara

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. Design Patterns
An Introduction
3

4. 4

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. 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. 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. 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. 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. 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. 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. (Reference: as3dp.com)
12

13. Enterprise Design
Pattern Catalogs
13

14. GOF Design Patterns
Enterprise Application Architecture
Design Patterns
Enterprise Integration Design Patterns
SOA Patterns
Security Patterns
Cloud Patterns
14

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. Gang of Four (GOF) Design Patterns Catalog
16

17. Enterprise Application Architecture Patterns
Catalog
(http://martinfowler.com/eaaCatalog)
17

18. Enterprise Intergration Patterns Catalog
http://www.eaipatterns.com/
18

19. GOF Design Patterns
An Introduction
19

20. 20

21. Behavioural Patterns
21

22. GOF Design Pattern
Organization
22

23. GOF Design Pattern
Relationships
23

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. Strategy Pattern
25

26. Strategy Pattern
26

27. Strategy Pattern
Reference: Head First Design Patterns
27

28. Reference: Head First Design Patterns
28

29. Reference: Head First Design Patterns
29

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. Command Pattern
Concrete
Command
Objects
Invoker
Receiver
31

32. Creational Patterns
32

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. The Simple Factory
34

35. The Simple Factory
35

36. Simple Factory
36

37. The Factory Method
The factory method pattern encapsulates the object
creation by letting subclasses to decide what objects
to create
37

38. The Factory Method
This is the
“Factory Method”
Factory objects are created
through INHERITANCE
38

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. Structural Patterns
40

41. Decorator Pattern
41

42. Decorator Pattern
42

43. Decorator Pattern
Cannot Connect
Can Connect
43

44. Decorator Pattern
44

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. ●
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. Facade Pattern
47

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. 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. 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. 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. Composite Pattern
Composites
Leaf Nodes
52

53. Composite Pattern
MenuComponent
Menu
MenuItem
MenuItems
53

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. 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

57. 57