Frameworks & Patterns Use of Organized Classes

Frameworks vs Toolkits Framework Framework  Start with classes and interfaces that define a rudimentary app  Subclass and override to produce your app  Use polymorphism Example Example  MVC Frameworks (e.g. Struts)  Extend the Controller class to register and handle your events. Specify your view  Extend the View to resppond to user actions, possibly forwarding Events to a Dispatcher  Extend the Dispatcher, adding controllers of your choice

Frameworks vs Toolkits Toolkits Toolkits  Provide general purpose functionality for reuse  Do not impose a design  User calls the reused code Example: Google Web Toolkit (GWT) Example: Google Web Toolkit (GWT)  Provides core Java APIs and Resources  Compile your app to Java Script  Result is an Ajax app running on iPhone, e.g.  E.g. Google Maps and Gmail

Frameworks vs Toolkits Framework: Reuse the frameworks main body and write the code it calls Framework: Reuse the frameworks main body and write the code it calls  Customize by creating application-specific subclasses of the framework’s abstract classes  Emphasizes design reuse over code reuse Toolkit: Write the main program and call the code you want to reuse Toolkit: Write the main program and call the code you want to reuse  Do not impose a design  Emphasize code reuse

Design Patterns Are a way of organizing classes to solve certain kinds of problems Are a way of organizing classes to solve certain kinds of problems “Each Design Pattern describes a problem which occurs over and over again... and then describes the core of the solution in such a way that you can use this solution a million times over, without ever doing it the same way twice.” --Gamma, et.al “Each Design Pattern describes a problem which occurs over and over again... and then describes the core of the solution in such a way that you can use this solution a million times over, without ever doing it the same way twice.” --Gamma, et.al

Design Patterns Components Name the pattern Name the pattern State the problem it solves, when to apply State the problem it solves, when to apply Give the solution as a template Give the solution as a template State the consequences and tradeoffs State the consequences and tradeoffs

Design Patterns vs Frameworks Frameworks are more specialized Frameworks are more specialized Design Patterns do not solve specific problems Design Patterns do not solve specific problems Frameworks are the way OOP systems achieve reuse Frameworks are the way OOP systems achieve reuse

Encapsulation An object’s internal state cannot be directly accessed--it’s representation is invisible from outside. An object’s internal state cannot be directly accessed--it’s representation is invisible from outside. Pertains to hiding of Pertains to hiding of  Data fields  Methods  Other objects  Subclasses

Encapsulation Example +display +unDisplay +fill +setLocation +getLocation +setColor Circle XCircle +displayIt +unDisplayIt +fillIt +setLocation +getLocation +SetItsColor Shape

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

Conclusions A program using a Shape only sees that, not a specific Shape. The abstract class Shape encapsulates the hierarchy of Shape subclasses A program using a Shape only sees that, not a specific Shape. The abstract class Shape encapsulates the hierarchy of Shape subclasses Abstract classes represent concepts Abstract classes represent concepts The operations represent a specification The operations represent a specification The concrete classes represent the implementation The concrete classes represent the implementation

The Open-Closed Principle Software units, e.g. classes or modules should be open for extension, but closed for modification Software units, e.g. classes or modules should be open for extension, but closed for modification  When a change in a program results in a cascade of changes to that program, then that program exhibits bad design  Design module/classes that never change  But be able to add new code, never changing old code that works The secret: Create fixed abstract entities that allow many possible behaviors The secret: Create fixed abstract entities that 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);..

Judgement This code does not adhere to the open- closed principle, because adding new Shapes would require modifying the code This code does not adhere to the open- closed principle, because adding new Shapes would require modifying the code Solution: Use an abstract Shape class and call the draw routines polymorphically Solution: Use an abstract Shape class and call 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? Say, draw all squares before circles Say, draw all squares before circles Define a method precedes on the Shapes Define a method precedes on the Shapes This will not work, because it is not closed against new Shapes This will not work, because it is not closed against new Shapes Also uses reflection Also uses reflection Better: use a table of class names Better: use a table of class names  Shapes not found always those that are

Conclusions Never, never use public data in a class--it can never be closed to change Never, never use public data in a class--it can never be closed to change No class, not even derived ones, should depend on the data fields of a given one No class, not even derived ones, should depend on the data fields of a given one Avoid run-time identification--use polymorphism Avoid run-time identification--use polymorphism Stay away from global variables Stay away from global variables