05/26/2004 www.indyjug.net 1

Indy Java User’s Group

May 26 2004

6:00p.m

@ Knowledge Services, Inc.

05/26/2004 www.indyjug.net 2

Agenda

•Welcome / Pizza 6:00-6:15

•Announcements 6:15-6:30

•Design Patterns 6:30-7:30

•Wrap-up / QA 7:30-8:00

05/26/2004 www.indyjug.net 3

Mission Statement

Promote the use of the Java language and components across all levels of interest in the greater Indianapolis area, by serving as a resource for knowledge, experience and career opportunities.

05/26/2004 www.indyjug.net 4

Announcements

•Next Meeting - June 30, 2004•JINI - Scott Ganyo

•Discussion Forumhttp://groups.yahoo.com/group/indyjug

•Websitewww.indyjug.net

05/26/2004 www.indyjug.net 5

Tonight’s Objective

•De-Mystify Design Patterns

•Introduce Gang of Four Design Pattern

•Demonstrate Decorator and Strategy

•Offer invitation for application

05/26/2004 www.indyjug.net 6

Design Patterns

•Goals of design patterns

•Published design patterns (GofF)

•Elements of a design pattern

•Categories of the GofF design patterns

05/26/2004 www.indyjug.net 7

Design Patterns (Goal)

•“Capture solutions that have developed and evolved over time in a succinct and easily applied form.”

•“Systematically name, explain and evaluate an important and recurring design in object-oriented systems”

05/26/2004 www.indyjug.net 8

Design Patterns (Published)

•Gang of Four•Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

•BookDesign Patterns: Elements of Reusable Object-Oriented Software

•ISBN 0-201-63361-2

•Copyright 1995 by Addison Wesley, Inc.

05/26/2004 www.indyjug.net 9

Design Patterns (Elements-1)

•Pattern Name (handle)•Higher level of abstraction•Vocabulary

•Problem (context)•Conditions that must be met before the pattern can be applied•Describe class or object structures

05/26/2004 www.indyjug.net 10

Design Patterns (Elements-2)

•Solution (elements)•Relationships•Responsibilities•Collaborations

•Consequences (trade-off)•Flexibility•Extensibility•Portability

05/26/2004 www.indyjug.net 11

Design Patterns (Categories)

•Creational Patterns •Factory Method, Singleton

•Structural Patterns•Adapter, Decorator

•Behavioral Patterns•Command, Iterator

05/26/2004 www.indyjug.net 12

Design Patterns (Creational)

•Creational design patterns abstract the instantiation process. They help make a system independent of how its objects are created, composed, and represented

(Factory, Singleton)

05/26/2004 www.indyjug.net 13

Design Patterns (Structural)

•Structural design patterns are concerned with how classes and objects are composed to form larger structures. (i.e. Inheritance)

(Adapter, Decorator)

05/26/2004 www.indyjug.net 14

Design Patterns (Behavioral)

•Behavioral design patterns are concerned with algorithms and the assignment of responsibilities between objects including the communication between them.

(Command, Iterator)

05/26/2004 www.indyjug.net 15

Design Patterns (Example)

•Need to create a table model to view and modify system data information.

•Options•Implement TableModel interface•Utilize the AbstractTableModel class•Utilize the DefaultTableModel class

05/26/2004 www.indyjug.net 16

Design Patterns (cont’d)

•Implement the TableModel interface

•Must declare all 9 methods including•Management of listeners•Column name resolution•Class type for a given column•Value at a given x,y coordinate•Editable state for x,y coordinate•Row and column counts

05/26/2004 www.indyjug.net 17

Design Patterns (cont’d)

•Utilize the AbstractTableModel class

•Must implement 3 methods•Value at a given x,y coordinate•Row counts•Column counts

•All other values are handled or defaulted.

05/26/2004 www.indyjug.net 18

Design Patterns (cont’d)

•Utilize the DefaultTableModel class

•No methods to implement

•Additional API •Ability to add a column•Ability to insert and move rows•Support for custom events

05/26/2004 www.indyjug.net 19

Design Patterns (Strategy)

Defines a family of algorithms, encapsulate each one, and make them interchangeable.

•Allows the algorithm to vary independently from clients that use it.

•Interface implementation

05/26/2004 www.indyjug.net 20

Design Patterns (Utilization)

•Utilize by inheritance.

Public class MyTableModel extends AbstractTableModel

•Utilization by decoration.

Public class MyTableModel implements TableModel

05/26/2004 www.indyjug.net 21

Design Patterns (Decorator)

•Attach additional responsibilities to an object dynamically.

•Flexible alternative to subclassing by attaching responsibility at runtime.

•Also called Wrapper•GofF example: Border and ViewText

05/26/2004 www.indyjug.net 22

Design Patterns (References)

Decorator: www.javaworld.com/javaworld/jw-04-2004/jw-0412-decorator_p.html

Strategy:www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns_p.html

Java Design Patterns Articles:http://www.javaworld.com/channel_content/jw-patterns-index.shtml

“Why Extends is Evil”:http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html

05/26/2004 www.indyjug.net 23

Design Patterns (Homework)

The client has several legacy applications that are all stand-alone. They want a single point user interface to allow the user to navigate between the various apps. What design pattern could you use that would allow you to not have to give knowledge to each legacy app about the client and not have to hard code all the legacy systems into the client code?

05/26/2004 www.indyjug.net 24

Indy Java User’s Group

Questions

05/26/2004 www.indyjug.net 25

Indy Java User’s Group

www.indyjug.net

05/26/2004 www.indyjug.net 26

Indy Java User’s Group