Frameworks & PatternsFrameworks & Patterns

Use of Organized ClassesUse of Organized Classes

Frameworks vs ToolkitsFrameworks vs Toolkits

• FrameworkFramework Start with classes and interfaces that define a Start with classes and interfaces that define a

rudimentary apprudimentary app Subclass and override to produce your appSubclass and override to produce your app Use polymorphismUse polymorphism

• ExampleExample MVC Frameworks (e.g. Struts)MVC Frameworks (e.g. Struts)

Extend the Controller class to register and handle your events. Extend the Controller class to register and handle your events. Specify your viewSpecify your view

Extend the View to resppond to user actions, possibly Extend the View to resppond to user actions, possibly forwarding Events to a Dispatcherforwarding Events to a Dispatcher

Extend the Dispatcher, adding controllers of your choiceExtend the Dispatcher, adding controllers of your choice

Frameworks vs ToolkitsFrameworks vs Toolkits

• ToolkitsToolkits Provide general purpose functionality for reuseProvide general purpose functionality for reuse Do not impose a designDo not impose a design User calls the reused codeUser calls the reused code

• Example: Google Web Toolkit (GWT)Example: Google Web Toolkit (GWT) Provides core Java APIs and ResourcesProvides core Java APIs and Resources Compile your app to Java ScriptCompile your app to Java Script Result is an Ajax app running on iPhone, e.g.Result is an Ajax app running on iPhone, e.g. E.g. Google Maps and GmailE.g. Google Maps and Gmail

Frameworks vs ToolkitsFrameworks vs Toolkits

• Framework: Reuse the frameworks main Framework: Reuse the frameworks main body and write the code it callsbody and write the code it calls Customize by creating application-specific Customize by creating application-specific

subclasses of the framework’s abstract classessubclasses of the framework’s abstract classes Emphasizes design reuse over code reuseEmphasizes design reuse over code reuse

• Toolkit: Write the main program and call the Toolkit: Write the main program and call the code you want to reusecode you want to reuse Do not impose a designDo not impose a design Emphasize code reuseEmphasize code reuse

Design PatternsDesign Patterns

• Are a way of organizing classes to solve Are a way of organizing classes to solve certain kinds of problemscertain kinds of problems

• ““Each Design Pattern describes a problem Each Design Pattern describes a problem which occurs over and over again ... and which occurs over and over again ... and then describes the core of the solution in then describes the core of the solution in such a way that you can use this solution a such a way that you can use this solution a million times over, without ever doing it the million times over, without ever doing it the same way twice.” --Gamma, et.alsame way twice.” --Gamma, et.al

Design Patterns ComponentsDesign Patterns Components

• Name the patternName the pattern• State the problem it solves, when to applyState the problem it solves, when to apply• Give the solution as a templateGive the solution as a template• State the consequences and tradeoffsState the consequences and tradeoffs

Design Patterns vs FrameworksDesign Patterns vs Frameworks

• Frameworks are more specializedFrameworks are more specialized• Design Patterns do not solve specific Design Patterns do not solve specific

problemsproblems• Frameworks are the way OOP systems Frameworks are the way OOP systems

achieve reuseachieve reuse

EncapsulationEncapsulation

• An object’s internal state cannot be directly An object’s internal state cannot be directly accessed--it’s representation is invisible accessed--it’s representation is invisible from outside.from outside.

• Pertains to hiding ofPertains to hiding of Data fieldsData fields MethodsMethods Other objectsOther objects SubclassesSubclasses

Encapsulation ExampleEncapsulation Example

+display+unDisplay+fill+setLocation+getLocation+setColor

Circle XCircle

+displayIt+unDisplayIt+fillIt+setLocation+getLocation+SetItsColor

Shape

EncapsulationEncapsulation

• Note that the class Note that the class CircleCircle encapsulates the encapsulates the XCircleXCircle classclass

• ““Consider what should be variable in your design. This Consider what should be variable in your design. This approach is the opposite if focusing on the cause of approach is the opposite if focusing on the cause of redesign. Instead of considering what might force a change redesign. Instead of considering what might force a change in design, consider what you might want to be able to in design, consider what you might want to be able to change without redesign. The focus here is on change without redesign. The focus here is on encapsulating the concept that varies, a theme of many encapsulating the concept that varies, a theme of many design patterns”--GoFdesign patterns”--GoF

• You can change design patterns without changing the You can change design patterns without changing the designdesign

ConclusionsConclusions

• A program using aA program using a Shape Shape only sees that, only sees that, not a specific not a specific ShapeShape. The abstract class . The abstract class ShapeShape encapsulates encapsulates the hierarchy of the hierarchy of ShapeShape subclasses subclasses

• Abstract classes represent conceptsAbstract classes represent concepts• The operations represent a specificationThe operations represent a specification• The concrete classes represent the The concrete classes represent the

implementationimplementation

The Open-Closed PrincipleThe Open-Closed Principle

• Software units, e.g. classes or modules Software units, e.g. classes or modules should be open for extension, but closed for should be open for extension, but closed for modificationmodification When a change in a program results in a When a change in a program results in a

cascade of changes to that program, then that cascade of changes to that program, then that program exhibits bad designprogram exhibits bad design

Design module/classes that never changeDesign module/classes that never change But be able to add new code, never changing But be able to add new code, never changing

old code that worksold code that works• The secret: Create fixed abstract entities The secret: Create fixed abstract entities

that allow many possible behaviorsthat allow many possible behaviors

enum ShapeType {Circle, Square}struct Shape{ ShapeType itsType;}struct Circle{ ShapeType itsType; double itsRadius; point itsCenter:}struct Square{ ShapeType itsType; double itsSide; point itsTopLeft;}void DraweSquare(struct Square *);void DrawCircle(struct Circle *);typedef struct Shape *ShapePointer;void drawAllShapes(ShapePointer list[], int n){ int i; for(i=0;i<n;i++){ struct Shape *s = list[i]; switch(s->itsType){ case Square: DrawSquare((struct Square*)s); break; case Circle: DrawCircle(“ “ “ Circle*)s);..

JudgementJudgement

• This code does not adhere to the open-This code does not adhere to the open-closed principle, because adding new closed principle, because adding new Shapes would require modifying the codeShapes would require modifying the code

• Solution: Use an abstract Solution: Use an abstract ShapeShape class and class and call the draw routines polymorphicallycall the draw routines polymorphically

public abstract class Shape{ public abstract void draw(); ...}public class Square extends Shape{ public void draw(); ...}public class Circle extends Shape{ public void draw(); ...}void drawAll(List list){ ListIterator it = list.listIterator(); while (it,hasNext()){ Shape obj = it.next(); obj.draw();}

What If You Now Modify?What If You Now Modify?

• Say, draw all squares before circlesSay, draw all squares before circles• Define a method precedes on the ShapesDefine a method precedes on the Shapes• This will not work, because it is not closed This will not work, because it is not closed

against new Shapesagainst new Shapes• Also uses reflectionAlso uses reflection• Better: use a table of class namesBetter: use a table of class names

Shapes not found always those that areShapes not found always those that are

ConclusionsConclusions

• Never, never use public data in a class--it Never, never use public data in a class--it can never be closed to changecan never be closed to change

• No class, not even derived ones, should No class, not even derived ones, should depend on the data fields of a given onedepend on the data fields of a given one

• Avoid run-time identification--use Avoid run-time identification--use polymorphismpolymorphism

• Stay away from global variablesStay away from global variables