R R R Frameworks A Brief Introduction R

R R R Frameworks A Brief Introduction

R R R Assigned Reading • Designing Reusable Classes: Johnson and Foote (JOOP 88) – Original Frameworks paper – Gives guidelines for creating frameworks – Motivates frameworks • See Handouts and Links web page

R R R Framework • Support reuse of detailed designs • An integrated set of components: – Collaborate to provide reusable architecture for – Family of related applications

R R R Frameworks 1. Frameworks are semi-complete applications 1. Complete applications are developed by inheriting from, and 2. Instantiating parameterized framework components 2. Frameworks provide domain-specific functionality 1. Ex. : business, telecommunication, dbases, distributed, OS kernels 3. Frameworks exhibit inversion of control at run-time 1. Framework determines which objects and methods to invoke in response to events

Class Libraries vs Frameworks vs Patterns R R R Application Specific Logic Invokes Event Loop Networking Math UI • Definition: ADTs – Class Libraries: • Self-contained, • Pluggable ADTs Dbase Class Library Architecture Math Networking Invokes ADTs Application Specific Call Backs Logic Dbase UI Event Loop Framework Architecture – Frameworks: • Reusable, semicomplete applications – Patterns: • Problem, solution, context

R R R Component Integration in Frameworks • Framework components are loosely coupled via “callbacks” • Callbacks allow independently developed software to be connected together • Callbacks provide a connection-point – Generic framework objects communicate with application objects – Framework provides common template methods – Application provides the variant hook methods

R R R Patterns vs Frameworks • Patterns and frameworks play complementary, cooperative roles • Patterns are more abstract descriptions of frameworks – Frameworks are implemented in specific language • Complex frameworks may involve dozens of patterns • Patterns may document frameworks

R R R GUI Framework • Model/View/Controller (MVC): – Smalltalk-80 UI framework • UI: 3 types of components: – models, views, controllers – view and controller objects interacting with model • Model: application object, UI-independent • View: manages region of display – Keeps it consistent with state of model – Can be nested to form complex UIs • Controller: converts user events (e. g. , mouse movements and key presses) into operations on its model and view

R R Example MVC R • Model: File. Browser • Views: – Top subview: String that is Pattern that matches set of files (e. g. , *. h) – Middle subview: displays list of files that match pattern (e. g. , Node. h, Int_node. h, etc. ) – Bottom Subview: displays selected file – Text. View (Top and Bottom subviews) – Selection. In. List. View: (Middle subview) • Controller: – Controller for each view – Mouse move from subview, activating different views

R R R • • Variations of MVC Framework Mac. App (Macintosh applications) Andrew Toolkit (CMU 88) Inter. Views (Stanford 89) Commercial: – z. App (OS-independent) – Open. Step (part of much bigger, comprehensive system) – Microsoft Foundation Classes

R R R Key Principles How to develop successful patterns and frameworks 1. Separate interface from implementation 2. Determine what is • • Common interface and (common -> stable) Variable implementation 3. Allow substitutions for variable implementations via a common interface Dividing commonality from variability should be goaloriented rather than exhaustive

R R R Open/Closed Principle • Determining common vs variable components is important – Insufficient variation makes it hard for users to customize framework components – Insufficient commonality makes it hard for users to understand depend upon framework’s behavior • Generally, dependency should always be in the direction of stability – Component should not depend on any component less stable than itself • Open/Closed Principle: – Allows most stable components to be extensible

R R Open/Closed Principle R • Components should be: – Open for extension – Closed for modification • Implications: – – Abstraction is good Inheritance and polymorphism are good Public data members and global data are bad Run-time type identification can be bad

R R R Violating Open/Closed Principle Struct Shape {/*. . . */}; Class Square : public Shape { /*. . . */} Class Circle : public Shape { /*. . . */} void draw_square {const Square &); void draw_circle {const Circle &); void draw_shape (const Shape &shape) { switch (shape. Type) { case SQUARE: draw Square ((const Square &) shape); break; case CIRCLE: draw Circle ((const Square &) shape); break; // etc.

R R R Applying Open/Closed Principle class Shape { public: virtual void draw () const = 0; }; void draw all (const Shape &shape){ shape. draw (); }

R R R Observations of Frameworks • Benefits of frameworks: – Enable direct reuse of code – Enable larger amounts of reuse than standalone functions or individual classes • Drawbacks: – High initial learning curve • Many classes, many levels of abstraction – Flow of control for reactive dispatching is nonintuitive – Verification/validation of generic components is hard