Pattern Based Development The Java Side of the

Pattern Based Development: The Java Side of the Story Jeff Highman Cortechs Inc GEN 604 Date

Objectives • Compare and contrast Advantage Gen pattern based development with objectoriented pattern based development • Introduce the J 2 EE pattern concepts • Explore various types • Introduce Frameworks and Anti-Patterns • Discuss how pattern based development was used for a successful J 2 EE EAI project

The Pattern Based Advantage • Allows you clone functional elements of an application for specific needs • Provides a mechanism for figuring out how to code to complex visual controls (treeview, grid, etc) • Eliminates the need to start from scratch • Gets you from ground-zero to working code very quickly

Advantage Patterns Copy with substitution A B C . . …………………. D E F . . ………………….

The Pattern Based Pitfalls Can facilitate the onewindow-per-table syndrome • Home grown patterns are often more expensive, more errorprone, and present a higher risk than commercially available patterns.

Templates Vs Java Patterns the differences • Often based on relational structures • Action Diagrams are procedural • Often implementation specific • Copy with substitution results in code replication • Imply a knowledge of action diagramming • Often associated with GUI look and feel • No ties to relational modeling • Seek to maximize the object-oriented aspects of Java • Are generic abstractions • Fundamental theme of J 2 EE patterns is write once and reuse. • Imply an understanding of the Java Language • Not connected to the GUI look and feel

Templates Vs Java Patterns the similarities • Promote standardization of solutions to problems • Enhance productivity • Are considered advanced development topics • Provide generic solutions to business problems

What is a J 2 EE Design Pattern? • Generalized solution to a recurring problem in a particular context • Product of Community Experience • Consist of four essential elements – Pattern name: a handle to denote a specific pattern – Problem: description of when to apply the pattern – Solution: description of the elements that make up the pattern including their relationship, responsibilities, and collaborations. – Consequences: the results and trade-offs of applying the pattern

Design Pattern Benefits • Capture design expertise • Facilitate reuse of successful designs and architectures • Establishes a common design vocabulary • Direct designers away from common design flaws • Provides for easier project transition from one designer to another • Typically reduce maintenance issues • Many patterns are applicable for J 2 SE as well as J 2 EE

History of Design Patterns • Architecture – Christopher Alexander wrote two books in 1977 and 1979. – The ideas presented are also applicable to software • 1987 – Ward Cunningham and Kent Beck – developed five patterns for UI design – Based on Alexander’s work – Published patterns in a paper • 1994 – “Gang of Four” published Design Patterns – Popularized Design Patterns

J 2 EE Pattern Types • Creational – Used for the creation of objects • Behavioral – Coordinate functional interaction between objects • Structural – Manage static, structural relationships between objects • System – Manage system level interaction of objects

Drafting Patterns Iterator Builder Decorator enumerating children creating composites saving state of iteration Composite adding responsibilities to objects sharing composites defining the chain defining grammar Flyweight sharing strategies Interpreter Adapter Visitor adding operations Strategy Proxy Bridge Memento Facade defining traversals Chain of Responsibility

Organising Patterns Pattern Catalogue Domain 1 Domain 2. . . Domain N Operational Informational Object Business Process Project 1 Project 2. . . Project N Version 1 Models Patterns Organisational Enterprise Rule . . . Version N Models Organisational Operational Informational Object Business Process Rule

J 2 EE Pattern Scope • Class – Micro-pattern that applies to a single class – Very specific, often accompanied with code as an example • Component – Focuses on a group of classes – Often presented with class and class interaction UML diagrams • Architectural – Macro-pattern, governs high-level design – Often presented in UML Component diagrams

Creational Patterns • Creational Patterns – Abstract Factory, Factory Method, Singleton – Concerned with object creation – Who creates what, when and how

Factory Method • Factory Method defines an interface for creating an object, but let subclasses decide which class to instantiate. • Factory Method lets a class defer instantiation to subclasses. • Frameworks use abstract classes to define and maintain relationships between objects. • A Framework is often responsible for creating these objects as well.

Factory Method Applicability Use the Factory Method pattern when • A class cannot anticipate the class of objects it must create. • A class wants its sub-classes to specify the objects it creates. • Classes delegate responsibility to one of several helper sub-classes, and you want to localize the knowledge of which helper sub-class is the delegate.

Singleton Pattern • The Singleton pattern ensures that a class has only one instance and provides a global point of access to it. • Examples: – There can be many printers in a system but there should only be one printer spooler. – There should be only one instance of a Window. Manager. – There should be only one instance of a filesystem.

Singleton Pattern • How do we ensure that a class has only one instance and that the instance is easily accessible? • A global variable makes an object accessible, but does not keep you from instantiating multiple objects. • A better solution is to make the class itself responsible for keeping track of its sole instance. The class ensures that no other instance can be created (by intercepting requests to create new objects) and it provides a way to access the instance.

Singleton Pattern Use the Singleton pattern when • 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.

Behavioral Patterns • Behavioral Patterns – Command, Observer, Mediator, Strategy – Characterize the ways in which classes or objects interact and distribute responsibility – Behavioral patterns are concerned with algorithms and the assignment of responsibilities between objects. – Behavioral patterns also describe patterns of communication between objects and classes.

Strategy pattern Intent. Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. Strategy Context. Interface() Structure Algorithm. Interface() Motivation A text compositor with a number of line breaking algorithms Concrete. Strategy. A Algorithm. Interface() Concrete. Strategy. B Algorithm. Interface() Concrete. Strategy. C Algorithm. Interface()

Structural Patterns • Structural Patterns – Adapter, Façade, Composite – Concerned with the composition of classes or objects – Structural class patterns use inheritance to compose interfaces or implementations. – Structural object patterns describe ways to compose objects to realize new functionality.

The Intermediary Pattern • A client interacts with an intermediary while the requested services are really carried out by the server/worker. 8 Proxy • Intermediary acts like a transmission agent. • E. g. , rpc rmi implementations. Client Proxy Server

Translator/Adapter Acts like a translator between the client and the server. Client Adapter Server

Facade • Intermediary acts like a focal point distributing work to other agents. • E. g. , telnet, ftp, … --> web-browser. • E. g. , local/network files, devices, . . . -> UNIX files Server 1 Client Facade Server 2 Server 3

Bridge/Abstract Factory/Handle Intermediary defines the interface but not the implementation. Impl 1 Client Bridge Impl 2 Impl 3

Model/View/Controller • Separates functional aspects into three distinct categories – Model is the data – View is the presentation – Controller coordinates the interaction of the Model and View • MVC is a fundamental pattern to Java Swing on a component level • MVC is also popular at the system level with frameworks like STRUTS and Cocoon

Frameworks • Frameworks specify – Structure – Flow – Data • Provide partial implementation of the infrastructure • Provide implementation of conceptual patterns • Available as COTS packages and open-source • Should be considered in early phases of J 2 EE project

Anti patterns • Recently Popularized way of re-thinking and refactoring well recognized patterns • A Anti-pattern tells you – Why a bad solution looks attractive – Why it turns out to be bad – What positive patterns are applicable in its stead • Anti-patterns allow you to see both sides of the coin to gain a better understanding