Frameworks & Patterns

1. Frameworks & Patterns Use of Organized Classes

2. Frameworks vs Toolkits • Framework • Start with classes and interfaces that define a rudimentary app • Subclass and override to produce your app • Use polymorphism • 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

3. Frameworks vs Toolkits • Toolkits • Provide general purpose functionality for reuse • Do not impose a design • User calls the reused code • 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

4. Frameworks vs Toolkits • 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 • Do not impose a design • Emphasize code reuse

5. Design Patterns • 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

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

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

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

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

10. Encapsulation • 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 • You can change design patterns without changing the design

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

12. The Open-Closed Principle • 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

13. 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);..

14. Judgement • 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

15. 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();}

16. What If You Now Modify? • Say, draw all squares before circles • Define a method precedes on the Shapes • This will not work, because it is not closed against new Shapes • Also uses reflection • Better: use a table of class names • Shapes not found always those that are

17. Conclusions • 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 • Avoid run-time identification--use polymorphism • Stay away from global variables