JAVA Design Patterns

Interfaces Interfaces define a contract Contain methods and their signatures Can also include static final constants (and comments) But no implementation Very similar to abstract classes One interface can extend another, but An interface cannot extend a class A class cannot extend an interface Classes implement an interface

Defining Interfaces Use the interface keyword public interface Vehicle { public void turnLeft(); public void turnRight(); } Like abstract methods, the signature is terminated with a semi-colon

Implementing Interfaces Use the implements keyword public class MotorBike implements Vehicle { //include methods from Vehicle interface } Class must implement all methods of the interface OR declare itself to be abstract Classes can implement any number of interfaces public class MotorBike implements Vehicle, Motorised Possible to combine extends and implements public class MotorBike extends WheeledVehicle implements Vehicle, Motorised

Sapana Mehta (CS-6V81) Design Patterns A pattern is a proven solution to a problem in a context. Christopher Alexander says each pattern is a three-part rule which expresses a relation between a certain context, a problem, and a solution. Design patterns represent a solutions to problems that arise when developing software within a particular context.

Categorizing Pattern Design Architectural Analysis Creational Patterns, then, represent expert solutions to recurring problems in a context and thus have been captured at many levels of abstraction and in numerous domains. Numerous categories are: Design Architectural Analysis Creational Structural Behavioral

Sun’s J2EE Framework Components Containers and Connectors: Hiding Complexity, Enhancing Portability Components are the key focus of application developers Containers intercede between clients and components, providing services transparently to both, including transaction support and resource pooling. Connectors sit beneath the J2EE platform, defining a portable service API to plug into existing enterprise vendor offerings.

J2EE and Design Patterns J2EE: AN OPERATING SYSTEM FOR THE WEB Enterprise web applications, which live on networks and are accessible through browsers, are redefining Enterprise Web Software. This is the next wave of computing. The J2EE architecture is built to enable component developers Design Pattern.

Java Pet Store- MVC Design Pattern The Java Pet Store is a reference application that demonstrates J2EE technologies. The Pet Store application implements MVC (Model-View-Controller) design, and demonstrates one way to design an application that should scale well.

ShoppingCart.jsp Java Server Pages (JSP)

Elements of Design Patterns Design patterns have 4 essential elements: Pattern name: increases vocabulary of designers Problem: intent, context, when to apply Solution: UML-like structure, abstract code Consequences: results and tradeoffs

Abstract Factory

Abstract Factory Provide an interface for creating families of related or dependent objects without specifying their concrete classes. The real-world example demonstrates the creation of different animal worlds for a computer game using different factories. Although the animals created by the Continent factories are different, the interactions among the animals remain the same.

Abstract Factory

Abstract Factory: Participants AbstractFactory Declares an interface for operations that create abstract products ConcreteFactory Implements the operations to create concrete product objects: usually instantiated as a Singleton AbstractProduct Declares an interface for a type of product object; Concrete Factories produce the concrete products ConcreteProduct Defines a product object to be created by the corresponding concrete factory

abstract class AbstractProductA{ public abstract void operationA1(); public abstract void operationA2(); } class ProductA1 extends AbstractProductA{ ProductA1(String arg){ System.out.println("Hello "+arg); } // Implement the code here public void operationA1() { }; public void operationA2() { };

class ProductA2 extends AbstractProductA{ ProductA2(String arg){ System.out.println("Hello "+arg); } // Implement the code here public void operationA1() { }; public void operationA2() { }; }

abstract class AbstractProductB{ //public abstract void operationB1(); //public abstract void operationB2(); } class ProductB1 extends AbstractProductB{ ProductB1(String arg){ System.out.println("Hello "+arg); } // Implement the code here

class ProductB2 extends AbstractProductB{ ProductB2(String arg){ System.out.println("Hello "+arg); } // Implement the code here }

abstract class AbstractFactory{ abstract AbstractProductA createProductA(); abstract AbstractProductB createProductB(); } class ConcreteFactory1 extends AbstractFactory{ AbstractProductA createProductA(){ return new ProductA1("ProductA1"); AbstractProductB createProductB(){ return new ProductB1("ProductB1");

class ConcreteFactory2 extends AbstractFactory{ AbstractProductA createProductA(){ return new ProductA2("ProductA2"); } AbstractProductB createProductB(){ return new ProductB2("ProductB2");

//Factory creator - an indirect way of instantiating the factories class FactoryMaker{ private static AbstractFactory pf=null; static AbstractFactory getFactory(String choice){ if(choice.equals("a")){ pf=new ConcreteFactory1(); }else if(choice.equals("b")){ pf=new ConcreteFactory2(); } return pf; }

// Client public class Client{ public static void main(String args[]){ AbstractFactory pf=FactoryMaker.getFactory("a"); AbstractProductA product=pf.createProductA(); //more function calls on product }

Consequences 1. Concrete class isolation (Good) Client does not interact with the implementation classes Client only manipulates instances through the abstract interfaces

Consequences 2. Product families easily exchanged (Good) Only have to change the concrete factory Can be done at run time

Consequences 3. Products are more consistent (Good) Helps the products in each product family consistently be applied together (assuming they work well together) Only one family at a time

Consequences 4. Difficult to support new kinds of products (Bad) Extending existing abstract factories to make new products is difficult and time consuming The family of products available is fixed by Abstract Factory interface

Singleton

Singleton Do we need to limit the no of objects of a class

Singleton Intent: Ensure that a class only has one instance, and provide a global point of access to it Applicability: There must be exactly one instance of a class, and it must be accessible to clients from a well-known access point When the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code

Singleton

Singleton Pattern Problem Context Solution core Want to ensure a single instance of a class, that’s shared by all uses throughout a program (e.g., the Portfolio) Context Need to address initialization versus usage ordering Solution core Provide a global access method (static member function) First use of the access method instantiates the class

Singleton Pattern Solution core Consequences Constructors for instance can be hidden (made private) Can hide destructor too if a “fini” method is also provided Consequences Object is never created if it’s never used Object is shared efficiently among all uses

Observer pattern Intent: Used in Model-View-Controller framework Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically Used in Model-View-Controller framework Model is problem domain View is windowing system Controller is mouse/keyboard control How can Observer pattern be used in other applications? JDK’s Abstract Window Toolkit (listeners) Java’s Thread monitors, notify(), etc.

Structure of Observer Pattern

Creational Patterns Abstract Factory: Builder: Factory Method: Factory for building related objects Builder: Factory for building complex objects incrementally Factory Method: Method in a derived class creates associates Prototype: Factory for cloning new instances from a prototype Singleton: Factory for a singular (sole) instance

Adapter Pattern Problem Have an object with an interface that’s close to (but is not exactly) what we need Context Want to re-use an existing class Can’t change its interface It’s impractical to extend class hierarchy more generally Solution Core Wrap a particular class or object with the interface needed (2 forms: class form and object forms)

Adapter «Adaptee» «Superclass» «Adapter» adaptedMethod polymorphicMethod «Adapter» polymorphicMethod() return adaptee.adaptedMethod(); { }

Adapter Structure (Class Form) Interface Impl method () = 0; impl_method (); public private Adapter method () { impl_method (); }; Interface abstract base class provides desired interface Impl concrete class provides the implementation Adapter glues them together via inheritance

Adapter Structure (Object Form) Interface method () = 0; impl_ Adapter Impl method () { impl_->impl_method(); }; impl_method (); Interface abstract base class provides desired interface Impl concrete class provides the implementation Adapter glues them together via delegation

Adapter Example TimsTorus ThreeDShape Sphere Torus volume() { return calcVolume ThreeDShape volume Sphere Torus volume() return adaptee.calcVolume(); { }

objects whose state can be watched Pattern: Observer objects whose state can be watched

Observer Intent Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. The object that changes state is called the subject and the other objects are the observers.

Observer design pattern In many programs, when object changes state, other objects may have to be notified Example: when a car in a game is moved The graphics engine needs to know to re-render item The traffic computation routines need to re-compute the traffic pattern Another example: data in a spreadsheet The display must be updated Possibly multiple graphs that use that data need to re-draw themselves This pattern answers the question: How best to notify those objects when the subject changes?

Motivation Separate presentation aspects of the UI from the underlying application data. e.g., spreadsheet view and bar chart view don't know about each other they act as if they do: changing one changes the other.

Observer: Structure

Observer pattern The key participants in this pattern are: The Subject, which provides an (virtual) interface for attaching and detaching observers The Observer, which defines the (virtual) updating interface The ConcreteSubject, which is the class that inherits/extends/implements the Subject The ConcreteObserver, which is the class that inherits/extends/implements the Observer