15
Introduction (Continued) Design Patterns (I) Lecture Two

Introduction (Continued) Design Patterns (I) Lecture Two

Embed Size (px)

Citation preview

Page 1: Introduction (Continued) Design Patterns (I) Lecture Two

Introduction (Continued)Design Patterns (I)

Lecture Two

Page 2: Introduction (Continued) Design Patterns (I) Lecture Two

What is a framework

• Like a class library, but more than an ordinary toolkit. The framework components have structural and behavioral relations among them.

• Domain specific:– business, telecom, window systems, databases,

OS kernels, …

Page 3: Introduction (Continued) Design Patterns (I) Lecture Two

What is a framework

• An integrated set of cooperating classes– architectural design of oo system– semi-complete application

• set of abstract class are specialized in application

Page 4: Introduction (Continued) Design Patterns (I) Lecture Two

Frameworks

• Inversion of control– main event loop is often in framework, rather

than in application code– hollywood principle: don’t call us, we’ll call

you– code in framework can invoke code in

application by dynamic binding

Page 5: Introduction (Continued) Design Patterns (I) Lecture Two

Framework examples

• UI– model-view-controller (MVC)

• framework for smalltalk user interfaces [1980]

– macapp - framework for Mac applications [1986]

• Others– MFC - Microsoft foundation classes– Choices - operating system framework– …..

Page 6: Introduction (Continued) Design Patterns (I) Lecture Two

Patterns vs Frameworks

• Patterns– reuse of design

– tells you how to do good design

– language independent

– often covers general domains

– addresses small part of a program architecture

Page 7: Introduction (Continued) Design Patterns (I) Lecture Two

Patterns vs Frameworks

• Framework– reuse of design and code

– is a design (generic implementation)

– language specific

– often covers specific domain

– addresses overall program architecture

Page 8: Introduction (Continued) Design Patterns (I) Lecture Two

State Pattern

• Butterfly Example– Caterpillar– Chrysalis– Adult

• Happy/Gloomy Example

Page 9: Introduction (Continued) Design Patterns (I) Lecture Two

State Pattern

• Book discussion– Applicability:

• state dependent behavior• large conditional statements

– Scheme: structure/participants/collaborations– Benefits

• extensibility• make state transitions explicit• can be shared (flyweight)

Page 10: Introduction (Continued) Design Patterns (I) Lecture Two

State Pattern

• Implementation– Who defines state transitions?– How about table-driven– Manage lifetime of state objects

• relation with Singleton

– How about use dynamic inhertiance

Page 11: Introduction (Continued) Design Patterns (I) Lecture Two

Singleton Pattern

• What is it?

• How to implement?

Page 12: Introduction (Continued) Design Patterns (I) Lecture Two

Homework: Digital Watch

• Demo

• Code explained

Page 13: Introduction (Continued) Design Patterns (I) Lecture Two

Composite Pattern

• Objective: treat primitives and containers uniformly

• java.awt.*

• Example Basket

Page 14: Introduction (Continued) Design Patterns (I) Lecture Two

Composite Pattern

• Consequences– recursive composition– uniform interface– easier to add new components– can make design overly general

Page 15: Introduction (Continued) Design Patterns (I) Lecture Two

Implementation Issues• Explicit parent references• Sharing components• Maximizing the Component interface• Child management operations• Who implements a list of components• Child ordering• Who should delete components• Best structures for storing components