A presentation on Design Patterns. This was created for the workshop at NED University of Engineering and Technology Karachi, Pakistan CIS Department held on April 7, 2012. Had a wonderful experience

1. DESIGN PATTERNS
Fahad Ali Shaikh

2. About Me
• CIS Graduate
• 3+ years experience in software development
• Asp.Net 3.5, Silverlight 3, Drupal
CMS, Android, CRM
• Currently CRM consultant at Sakonent
• Passionate Technology Trainer
• Wing Chun Kung Fu student
• Google Fahad Ali Shaikh for more 

3. Agenda
• What are Design Patterns and why should we
use them?
• Let’s strengthen our OOP.
• Creational Pattern
– Singleton
– Factory Pattern
• Behavioral Patterns
– Strategy Pattern
– Observer Pattern

4. Agenda
• Structural Patterns
– Decorator Pattern
• Architectural Patterns
– MVC

5. What are DP and Why DP?

6. What are DP and Why DP?
• A design pattern is a documented best
practice or core of a solution that has been
applied successfully in multiple environments
to solve a problem that recurs in a specific set
of situations.
• Patterns address solution to a problem

7. What are DP and Why DP?
• Focus on solving the MAIN problem rather
than the small ones

8. What are DP and Why DP?
• Someone has already done what you want to
do

9. What are DP and Why DP?
• A shared language for communicating the
experience gained in dealing with these
recurring problems and their solutions

10. What are DP and Why DP?
• Patterns are discovered not invented

11. What are DP and Why DP?
• Patterns are used effectively with experience

12. Design Patterns Categories
Purpose Design Pattern Aspects that can vary
Creational Abstract Factory Families of product objects
Singleton Creation of a single object
Factory Method Subclass of object instantiated
Structural Adapter Interface to an object
Facade Interface to a subsystem
Flyweight Storage costs of objects
Proxy How an object is accessed
Behavioral Command When & how a request is fulfilled
Iterator Traversal of elements in an
aggregate

13. Lets Strengthen Our OOP!

14. Lets Strengthen Our OOP!
• Tight Encapsulation
• Encapsulation refers to the combining of
fields and methods together in a class
such that the methods operate on the
data, as opposed to users of the class
accessing the fields directly.

15. Lets Strengthen Our OOP!
• Loose Coupling
• Coupling is the extent to which one object
depends on another object to achieve its
goal.

16. Lets Strengthen Our OOP!
• Loose Coupling
–Coupling is the extent to which one
object depends on another object
to achieve its goal.

17. Lets Strengthen Our OOP!
• Loose Coupling
• public class Address {
• public String street;
• public String city;
• public int zip;
• }

18. Lets Strengthen Our OOP!
• Not so Loose Coupling
• public class Employee {
• private Address home;
• public Employee(String street, String city, int zip) {
• home = new Address();
• home.street = street;
• home.city = city;
• home.zip = zip;
}
• }

19. Lets Strengthen Our OOP!
• Loose Coupling
• Encapsulate – Use getters and setters

20. Lets Strengthen Our OOP!
• High Cohesion
• Cohesion refers to how closely related
the specific tasks are of an object.
• High cohesion is when an object performs
a collection of closely related tasks.

21. Lets Strengthen Our OOP!
• High Cohesion
• public class Payroll {
• public void computeEmployeePay() {
• System.out.println(“Compute pay for employees”);
• }
• public void computeEmployeeTaxes() {
• System.out.println(“Compute taxes for employees”);
• }
• public void addNewEmployee(Employee e) {
• System.out.println(“New employee hired...”);
• }
• }

22. Lets Strengthen Our OOP!
• Composition vs Inheritance

23. The Strategy Pattern
• Composition vs Inheritance

24. The Strategy Pattern
• Define a family of
algorithms, encapsulate each
one, and make them
interchangeable.
• Strategy lets the algorithm vary
independently from clients that use
it.

25. The Strategy Pattern

26. The Strategy Pattern

27. But now we need ducks to fly

28. The Strategy Pattern

29. The Strategy Pattern

30. The Strategy Pattern

31. The Strategy Pattern

32. The Strategy Pattern

33. The Strategy Pattern

34. What do you think about this design?

35. The Strategy Pattern

36. The Strategy Pattern

37. The Strategy Pattern

38. The Strategy Pattern

39. The Strategy Pattern

40. The Strategy Pattern

41. The Strategy Pattern

42. The Strategy Pattern

43. The Strategy Pattern

44. The Singleton Pattern

45. The Singleton Pattern
• Ensures a class has only one instance
• Provides a single point of reference

46. The Singleton Pattern – Use When
• There must be exactly one instance of a
class.
• May provide synchronous access to
avoid deadlocks.
• Very common in GUI toolkits, to specify
the connection to the OS/Windowing
system

47. The Singleton Pattern - Benefits
• Controls access to a scarce or unique
resource
• Helps avoid a central application class with
various global object references
• Subclasses can have different
implementations as required. Static or
global references don’t allow this
• Multiple or single instances can be allowed

48. The Singleton Pattern
public class ClassicSingleton {
private static ClassicSingleton instance = null;
protected ClassicSingleton() {
// exists only to defeat instantiation.
//should be private and final for performance
}
public static ClassicSingleton getInstance() {
if(instance == null) {
instance = new ClassicSingleton();
}
return instance;
}
}

49. The Factory Pattern
The Factory pattern returns an instance of one of several possible
classes depending on the data provided to it.
 Here, x is a base class and classes xy and xz are derived from it.
 The Factory is a class that decides which of these subclasses to
return depending on the arguments you give it.
 The getClass() method passes in some value abc, and returns
some instance of the class x. Which one it returns doesn't matter
to the programmer since they all have the same methods, but
different implementations.

50. The Factory Pattern
The Factory pattern returns an instance of one of several possible
classes depending on the data provided to it.
 Here, x is a base class and classes xy and xz are derived from it.
 The Factory is a class that decides which of these subclasses to
return depending on the arguments you give it.
 The getClass() method passes in some value abc, and returns
some instance of the class x. Which one it returns doesn't matter
to the programmer since they all have the same methods, but
different implementations.

51. The Factory Pattern
 Suppose we have an entry form and we want to allow the user to enter his
name either as “firstname lastname” or as “lastname, firstname”.
 Let’s make the assumption that we will always be able to decide the name
order by whether there is a comma between the last and first name.
class Namer { //a simple class to take a string apart into two names
protected String last; //store last name here
protected String first; //store first name here
public String getFirst() {
return first; //return first name
}
public String getLast() {
return last; //return last name
}
}

52. The Factory Pattern
In the FirstFirst class, we assume that everything before the last
space is part of the first name.
class FirstFirst extends Namer {
public FirstFirst(String s) {
int i = s.lastIndexOf(" "); //find sep space
if (i > 0) {
first = s.substring(0, i).trim(); //left is first name
last =s.substring(i+1).trim(); //right is last name
} else {
first = “” // put all in last name
last = s; // if no space
}
}
}

53. The Factory Pattern
In the LastFirst class, we assume that a comma delimits the last
name.
class LastFirst extends Namer { //split last, first
public LastFirst(String s) {
int i = s.indexOf(","); //find comma
if (i > 0) {
last = s.substring(0, i).trim(); //left is last name
first = s.substring(i + 1).trim(); //right is first name
} else {
last = s; // put all in last name
first = ""; // if no comma
}
}
}

54. The Factory Pattern
The Factory class is relatively simple. We just test for the existence
of a comma and then return an instance of one class or the other.
class NameFactory {
//returns an instance of LastFirst or FirstFirst
//depending on whether a comma is found
public Namer getNamer(String entry) {
int i = entry.indexOf(","); //comma determines name order
if (i>0)
return new LastFirst(entry); //return one class
else
return new FirstFirst(entry); //or the other
}
}

55. The Factory Pattern
NameFactory nfactory = new NameFactory();
String sFirstName, sLastName;
….
private void computeName() {
//send the text to the factory and get a class back
namer = nfactory.getNamer(entryField.getText());
//compute the first and last names using the returned class
sFirstName = namer.getFirst();
sLastName = namer.getLast();
}

56. The Factory – When to use
You should consider using a Factory pattern
when:
 A class can’t anticipate which kind of class of
objects it must create.
 A class uses its subclasses to specify which
objects it creates.
 You want to localize the knowledge of which
class gets created.

57. Feeling hungry ?

58. Let’s have a break

59. The Observer Pattern
 The cases when certain objects need to be
informed about the changes which occurred
in other objects and are frequent.

60. The Observer Pattern
 The cases when certain objects need to be
informed about the changes which occurred
in other objects and are frequent.
 Define a one-to-many dependency between
objects so that when one object changes
state, all its dependents are notified and
updated automatically.

61. The Observer Pattern
• This pattern is a cornerstone of the Model-
View-Controller architectural design, where
the Model implements the mechanics of the
program, and the Views are implemented as
Observers that are as much uncoupled as
possible to the Model components.

62. The Observer Pattern
• The participants classes in the Observer pattern are:
•
Observable - interface or abstract class defining the operations for
attaching and de-attaching observers to the client. In the GOF
book this class/interface is known as Subject.
• ConcreteObservable - concrete Observable class. It maintain the
state of the observed object and when a change in its state occurs
it notifies the attached Observers.
• Observer - interface or abstract class defining the operations to be
used to notify the Observer object.
• ConcreteObserverA, ConcreteObserverB - concrete Observer
implementations.

63. The Observer Pattern
• Observable()
• Construct an Observable with zero Observers.
• void addObserver(Observer o)
• Adds an observer to the set of observers for this
object, provided that it is not the same as some observer
already in the set.
• protected void clearChanged()
• Indicates that this object has no longer
changed, or that it has already notified all of its
observers of its most recent change, so that the hasChanged
method will now return false.
• int countObservers()
• Returns the number of observers of this
Observable object.
• void deleteObserver(Observer o)
• Deletes an observer from the set of observers of
this object.
• void deleteObservers()
• Clears the observer list so that this object no
longer has any observers.

64. The Observer Pattern
• boolean hasChanged()
• Tests if this object has changed.
• void notifyObservers()
• If this object has changed, as indicated by
the hasChanged method, then notify all of its
observers and then call the clearChanged method to
indicate that this object has no longer changed.
• void notifyObservers(Object arg)
• If this object has changed, as indicated by
the hasChanged method, then notify all of its
observers and then call the clearChanged method to
indicate that this object has no longer changed.
• protected void setChanged()
• Marks this Observable object as having been
changed; the hasChanged method will now return true.

65. The Observer Pattern
• // A Sub-class of Observable: a Clock Timer
• import java.util.Observable;
• class ClockTimerModel extends Observable {
public:
ClockTimer();
• int GetHour(){return hour};
int GetMinute(){return minute};
int GetSecond(){return second};
• void tick(){
• // update internal time-keeping state ……………………
// The Observable object notifies all its registered observers
setChanged();
• notifyObservers();};
• private:
• int hour;
• int minute;
• int second;
};
• In green are the changes to be applied to the class to be made an observable
class.

66. The Observer Pattern
• public void update(Observable o, Object arg)
• This method is called whenever the observed
object is changed. An application calls an
Observable object's notifyObservers method to
have all the object's observers notified of
the change.
• Parameters:
• o - the observable object.
• arg - an argument passed to the
notifyObservers method.

67. The Observer Pattern
• // A specific Observer to observe ClockTimerModel:
DigitalClockView
• //
• import java.util.Observer;
• class DigitalClockView implements Observer {
• public void update(Observable obs, Object x) {
• //redraw my clock’s reading
draw();};
•
void draw(){
int hour = obs.GetHour();
int minute = obs.GetMinute();
int second = obs.GetSecond();
• // draw operation};
• };

68. The Observer Pattern
• public class ObserverDemo extends Object {
• DigitalClockView clockView;
• ClockTimerModel clockModel;
• public ObservDemo() {
• clockView = new DigitalClockView();
• clockModel = new ClockTimerModel();
• clockModel.addObserver(clockView);
• }
• public static void main(String[] av) {
• ObserverDemo me = new ObserverDemo();
• me.demo();
• }
• public void demo() {
• clockModel.Tick();
• }

69. The Decorator Pattern

70. The Decorator Pattern

71. First Idea of Implementation

72. In Reality

73. Now a beverage can be mixed from different condiment to form
a new

76. Now, your turns. It is a good solution?

77. Take some time to complete

78. What can you criticize about this
inheritance architecture?
Write down your notes to see if you are right…
3 minutes….

79. Ok time’s up.

81. The Problem
• The problems of two previous designs
– we get class explosions, rigid designs,
– or we add functionality to the base class that
isn’t appropriate for some of the subclasses.

82. The Problem Revisited
• If a customer wants a Dark Roast with Mocha
and Whip
– Take a DarkRoast object
– Decorate it with a Mocha object
– Decorate it with a Whip object
– Call the cost() method and rely on
– delegation to add on the condiment costs

83. Decorator at action

84. Decorator at action

85. Decorator at action

86. Decorator at action

87. Decorator Pattern Defined

88. Decorator Pattern for StarBuzz Bevereges

89. Let’s see some code…

90. Abstract class for condiments

91. Concrete base class for beverages

92. Concrete condiment class

93. Constructing the new beverages instance
dynamically

94. Constructing the new beverages instance
dynamically

95. Model View Controller

96. MVC

97. Questions ?