Design Patterns

Introduction  Different Types of Patterns  Factory Pattern  Value Object Pattern  Session Faade Pattern  Q & A Session


What are Design Patterns?



Design Patterns capture solutions that have developed and evolved over time . They reflect untold redesign and recoding as developers have struggled for greater reuse and flexibility in their software. Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.

Brief History of Patterns

In 1970, Christopher Alexander documented patterns in Civil Engineering and architecture  Design Patterns: Elements of Reusable ObjectObject-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides Addison-Wesley, 1995 his Addisonis also known as the Gang-of-Four book. Gang-of

Why Study Design Patterns?

Develop better products.  Learn from others experience.  Improve communication with others in the same field.  Dont reinvent the wheel.


Benefits of Design Patterns



Design patterns enable large-scale reuse of software architectures.  They also help document systems to enhance understanding. Patterns explicitly capture expert knowledge and design tradeoffs, and make this expertise more widely available. Patterns help improve developer communication.  Pattern names form a vocabulary Patterns help ease the transition to object-oriented technology.

What Makes it a Pattern?

 

A pattern must: solve a problem, problem,  it must be useful! have a context, context,  It must describe where the solution can be used. recur, recur,  It must be relevant in other situations.

Teach, Teach,  It must provide sufficient understanding to tailor the solution. have a name. name.  It must be referred to consistently.

Common Design Patterns

The Gang of Four (GOF) patterns are generally considered the foundation for all other patterns.  They are categorized in three groups:  Creational  Structural  Behavioral.


Explanation


Creational patterns are ones that create objects for you, rather than having you instantiate objects directly. This gives your program more flexibility in deciding which objects need to be created for a given case. Structural patterns help you compose groups of objects into larger structures, such as complex user interfaces or accounting data.

Explanation


Behavioral patterns help you define the communication between objects in your system and how the flow is controlled in a complex program.

Creational Pattern


Abstract Factory  Creates an instance of several families of classes Builder  Separates object construction from its representation Factory Method  Creates an instance of several derived classes

Creational Pattern
Prototype  A fully initialized instance to be copied or cloned  Singleton  A class of which only a single instance can exist


Structural Pattern


Adapter  Match interfaces of different classes Bridge  Separates an objects interface from its implementation Composite  A tree structure of simple and composite objects Decorator  Add responsibilities to objects dynamically

Structural Pattern
Faade  A single class that represents an entire subsystem  Flyweight  A fine-grained instance used for efficient finesharing  Proxy  An object representing another object


Behavioral Pattern


Chain of Resp.  A way of passing a request between a chain of objects Command  Encapsulate a command request as an object Interpreter  A way to include language elements in a program Iterator  Sequentially access the elements of a collection

Behavioral Pattern


Mediator  Defines simplified communication between classes Memento  Capture and restore an object's internal state Observer  A way of notifying change to a number of classes State  Alter an object's behavior when its state changes

Behavioral Pattern


Strategy  Encapsulates an algorithm inside a class Template Method  Defer the exact steps of an algorithm to a subclass Visitor  Defines a new operation to a class without change

Factory Pattern
A Factory pattern is one that returns an instance of one of several possible classes depending on the data provided to it.  Usually all of the classes it returns have a common parent class and common methods, but each of them performs a task differently and is optimized for different kinds of data.


Problem


Sometimes, an Application at runtime, cannot anticipate the class of object that it must create. It may know that it has to instantiate classes, but it may only know about abstract classes (or interfaces), which it cannot instantiate. Thus the Application class may only know when it has to instantiate a new Object of a class, not what kind of subclass to create.

Problem


a class may want it's subclasses to specify the objects to be created. a class may delegate responsibility to one of several helper subclasses so that knowledge can be localized to specific helper subclasses.

Solution


It helps to model an interface for creating an object which at creation time can let its subclasses decide which class to instantiate. It helps instantiate the appropriate Subclass by creating the right Object from a group of related classes. The Factory Pattern promotes loose coupling by eliminating the need to bind application-specific applicationclasses into the code.

Factory Pattern

Factory Pattern

Base Class
class Namer { protected String last; protected String first; public String getFirst() { return first;} public String getLast() { return last;}}

Derived Class
class FirstFirst extends Namer { public FirstFirst(String s) { int i = s.lastIndexOf(" "); if (i > 0) { first = s.substring(0, i).trim(); last =s.substring(i+1).trim();} else { first = ; last = s; }}}

Another Derived Class

class LastFirst extends Namer { public LastFirst(String s) { int i = s.indexOf(","); if (i > 0) { last = s.substring(0, i).trim(); first = s.substring(i + 1).trim();} else { last = s; first = "";}}}

Building the Factory

class NameFactory { public Namer getNamer(String entry) { int i = entry.indexOf(","); if (i>0) return new LastFirst(entry); else return new FirstFirst(entry); }}

Value Object Pattern Problem

When a client calls a remote method there will be process of marshalling, network calls and unmarshalling involved for the remote method invocation.  fine grained approach when calling methods remotely involves significant network overhead.


Problem
remoteObject.getName(); remoteObject.getCity(); remoteObject.getState(); Here every method call is remote method call

Value Object Method Calls

Solution through Value Object



The solution for avoiding many network calls due to fine grained method calls is to use coarse grained approach  Create an Value Object and fill that object locally

Solution
PersonInfo person = new PersonInfo(); person.setName("Ravi"); person.setCity("Austin"); person.setState("TX"); send Value Object through network remoteObject.getPersonInfo(person);

Solution

Session Faade Problem

EJB clients (swing, servlets, jsps etc) can access entity beans directly.  If EJB clients access entity beans directly over the network, it takes more network calls and imposes network overhead.


Problem

Solution
The solution for avoiding number of network calls due to directly accessing multiple entity beans is to wrap entity beans with session bean (Facade).  The EJB client accesses session bean (Facade) instead of entity beans through coarse grained method call to accomplish a business process.


Solution

Solution
  

Here the client makes only one coarse grained method call to session bean (facade). The session bean in turn calls entity beans to process client request. Entity beans can be made local by implementing local interfaces to reduce remote overhead etween session facade and entity beans. Therefore the session facade reduces the network traffic and increases performance.

Drawbacks to Design Patterns



   

Patterns do not lead to direct code reuse.  For reuse of code: O-O Frameworks == Design Patterns + Code Patterns are deceptively simple. Teams may suffer from pattern overload. Patterns are validated by experience and discussion rather than by automated testing. Integrating patterns into a software development process is a human-intensive activity.

Misconceptions of Patterns


 

A Pattern is a solution to a problem in a context  Missing Recurrence, Teaching and a Name Patterns are just jargon, rules, programming tricks, data structures, etc.. Seen one, seen them all Patterns need tool or methodological support to be effective

Misconceptions of Patterns


 

Patterns guarantee reusable software, higher productivity, etc Patterns generate whole software architectures Patterns are for (object-oriented) design or (objectimplementation  Design Patterns are not the only type of software pattern! Theres no evidence that patterns help anybody

References
http://www.precisejava.com/javaperf/j2ee/P atterns.htm#Patterns102  The Design Patterns Java Companion By James Cooper


Q&A Session