Design patterns(red)

DESIGN PATTERNS

Fahad Ali Shaikh

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 

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

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

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


• Focus on solving the MAIN problem rather
than the small ones


• Someone has already done what you want to
do


• A shared language for communicating the
experience gained in dealing with these
recurring problems and their solutions


• Patterns are discovered not invented


• Patterns are used effectively with experience

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

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.

• Loose Coupling
• Coupling is the extent to which one object
depends on another object to achieve its
goal.

• Loose Coupling
–Coupling is the extent to which one
object depends on another object
to achieve its goal.

• Loose Coupling

• public class Address {
• public String street;
• public String city;
• public int zip;
• }

• 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;
}
• }


• Loose Coupling
• Encapsulate – Use getters and setters

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

• 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...”);
• }
• }

• Composition vs Inheritance

The Strategy Pattern
• Composition vs Inheritance

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.

What do you think about this design?

The Singleton Pattern
• Ensures a class has only one instance

• Provides a single point of reference

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

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

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;
}
}

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.

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

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

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

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

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();
}

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.

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

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

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

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

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

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

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


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

• // 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};
• };

• 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();
• }

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

Now, your turns. It is a good solution?

What can you criticize about this
inheritance architecture?

Write down your notes to see if you are right…
3 minutes….

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.

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

Decorator Pattern for StarBuzz Bevereges

Concrete base class for beverages

Constructing the new beverages instance
dynamically

Design patterns(red)

More Related Content

What's hot

Viewers also liked

Similar to Design patterns(red)

Recently uploaded

Design patterns(red)

Editor's Notes