No Slide Title

Download Report

Transcript No Slide Title

Indy Java User’s Group
May 26 2004
6:00p.m
@ Knowledge Services, Inc.
05/26/2004
www.indyjug.net
1
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
2
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
3
Announcements
•Next Meeting - June 30, 2004
•JINI - Scott Ganyo
•Discussion Forum
http://groups.yahoo.com/group/indyjug
•Website
www.indyjug.net
05/26/2004
www.indyjug.net
4
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
5
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
6
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
7
Design Patterns (Published)
•Gang of Four
•Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
•Book
Design Patterns: Elements of Reusable Object-Oriented Software
•ISBN 0-201-63361-2
•Copyright 1995 by Addison Wesley, Inc.
05/26/2004
www.indyjug.net
8
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
9
Design Patterns (Elements-2)
•Solution (elements)
•Relationships
•Responsibilities
•Collaborations
•Consequences (trade-off)
•Flexibility
•Extensibility
•Portability
05/26/2004
www.indyjug.net
10
Design Patterns (Categories)
•Creational Patterns
•Factory Method, Singleton
•Structural Patterns
•Adapter, Decorator
•Behavioral Patterns
•Command, Iterator
05/26/2004
www.indyjug.net
11
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
12
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
13
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
14
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
15
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
16
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
17
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
18
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
19
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
20
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
21
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-0426designpatterns_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
22
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
23
Indy Java User’s Group
Questions
05/26/2004
www.indyjug.net
24
Indy Java User’s Group
www.indyjug.net
05/26/2004
www.indyjug.net
25
Indy Java User’s Group
05/26/2004
www.indyjug.net
26