Frameworks

1
Frameworks

• A Brief Introduction

2
Assigned Reading

• Designing Reusable Classes Johnson and Foote
  (JOOP88)
• Original Frameworks paper
• Gives guidelines for creating frameworks
• Motivates frameworks
• See Handouts and Links web page

3
Framework

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

4
Frameworks

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

5
Class Libraries vs Frameworks vs Patterns

• Application
• Specific
• Logic

Networking

• Definition
• Class Libraries
• Self-contained,
• Pluggable ADTs
• Frameworks
• Reusable, semi-complete applications
• Patterns
• Problem, solution, context

ADTs
Invokes
Math
Event Loop
Dbase
UI
Class Library Architecture
Math
Networking
UI
Application Specific Logic
Invokes
Call Backs
ADTs
Event Loop
Dbase
Framework Architecture
6
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

7
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

8
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
• Implement scrolling and menus

9
Example MVC

• Model FileBrowser
• 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
• TextView (Top and Bottom subviews)
• SelectionInListView (Middle subview)
• Controller
• Controller for each view
• Mouse move from subview, activating different
  views

10
Variations of MVC Framework

• MacApp (Macintosh applications)
• Andrew Toolkit (CMU 88)
• InterViews (Stanford 89)
• Commercial
• zApp (OS-independent)
• OpenStep (part of much bigger, comprehensive
  system)
• Microsoft Foundation Classes

11
Key Principles

• How to develop successful patterns and frameworks
• Separate interface from implementation
• Determine what is
• Common interface and (common -gt stable)
• Variable implementation
• Allow substitutions for variable implementations
  via a common interface
• Dividing commonality from variability should be
  goal-oriented rather than exhaustive

12
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 and depend upon frameworks
  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

13
Open/Closed Principle

• 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

14
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.shapeType)
• case SQUARE
• draw Square ((const Square ) shape)
• break
• case CIRCLE
• draw Circle ((const Square ) shape)
• break
• // etc.

15
Applying Open/Closed Principle

• class Shape
• public
• virtual void draw () const 0
• void draw all (const Shape shape)
• shape.draw ()

16
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
  non-intuitive
• Verification/validation of generic components is
  hard