More Frameworks

1. More Frameworks • Acknowledgements: • K. Stirewalt • R. Johnson, B. Foote • Johnson, Fayad, Schmidt

2. Overview Review of object-oriented programming (OOP) principles. Intro to OO frameworks: Key characteristics. Uses. Black-box vs. white-box frameworks. Example study: Animations in the subArctic UI toolkit.

3. Recap on OOP • Key features that differentiate OOP from traditional block-structured languages: • Polymorphism: a late-binding feature, whereby a procedure is dynamically bound to a message request. • Inheritance: allows operations to be defined in one (parent) class and then overridden in another (child) class. • Inheritance and polymorphism together are the principle tools of OO frameworks.

4. Inheritance and polymorphism • Subclasses provide different methods for same operation. • Benefit: Enables decoupling of cooperating classes. • Clients need not know how an operation is implemented. • Thus, designs are portable and extensible. • Code can be reused. • Two cases: • Superclass provides a method for the operation. • we say the subclass overrides this method. • subclass method may explicitly invoke superclass method. • Superclass provides no method for the operation. • we say the operation is abstract in the superclass.

5. Protocol • Operations performed on objects by ``sending them messages''. • Specification of an object given by its message protocol: • Set of messages that can be sent to it; • Includes type of arguments of each message. • Objects with identical protocol are interchangeable. • Interface between objects defined by protocols they expect each other to understand. • In most languages, protocol is bound to an object's class1.

6. Abstract classes • Defn: class that cannot have any instances. • Only subclasses can have instances. • How to specify that a class is abstract: • C++: Implicit; abstract class has pure virtual functions. • Java: • Class can be explicitly declared abstract, or • Abstract operations can be grouped into an interface. • Used to define standard protocols.

7. Use of Abstract Class to Represent a Protocol

8. Abstract Operations and Design Coupling • Imagine:a tool that places figures on a grid. • Example: gridding of program icons in a window manager. • Example: placement of button figures in a panel. • Grid-management code allocates figures to grid positions, avoiding collisions and possibly implementing a fill policy. • Code should not be concerned with how to draw a figure. • Question:How do you separate grid management from the drawing of figures?

9. Example Decoupling using abstract operations

10. Example: Use of these classes #include "Square.h" #include "Triangle.h" #include "Circle.h" #include "Grid.h" ... Grid myGrid; ... myGrid.AddFigure( new Square ); myGrid.AddFigure( new Triangle ); myGrid.AddFigure( new Circle ); myGrid.Draw();

11. Example: continued class Figure : public WindowComponent { public: virtual void Draw() = 0; // pure virtual function! };   class Grid : public WindowComponent { public: void AddFigure( Figure* ); void Draw() { for( int i=0; i < 3; ++i ) { figures[i].Draw(); } private: Figure* figures[3]; };

12. Plug Compatibility • If several classes define same protocol, then objects in those classes are plug compatible. • Thus complex objects can be created by plugging together a set of compatible components. • Style of programming called building tool kits.

13. Intro to OO Frameworks

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

15. 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

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

17. Characteristics of Frameworks • Often: • User-defined methods invoked by the framework code itself. • Framework plays the role of ``main program''. • This inversion of control allows frameworks to serve as extensible code skeletons. • User-supplied methods tailor generic framework algorithms for a specific application.

18. Object-Oriented Frameworks • A.k.a: Object-oriented abstract design. • Consists of: • Abstract class for each major component; • Interfaces between components defined in terms of sets of messsages. • Usually a library of subclasses that can be used as components in the design. • Many well-known examples: • All modern UI toolkits (e.g., Java AWT, subArctic, MFC). • Distributed computing toolkits (e.g., ACE).

19. Example: Java AWT Framework (abstracted)

20. Whitebox Frameworks • Program skeleton: • Subclasses are the additions to skeleton • Implications: • Framework implementation must be understood to use • Every application requires the creation of many new subclasses • Can be difficult to learn: • Need to need how it was constructed (hierarchical structure) • State of each instance is implicitly available to all methods in framework (i.e., similar to global vars)

21. Example: Event handling in Java AWT 1.02 and before • Events are propagated from components to their containers until such time as the event is serviced. • Every component has the operation: public boolean handleEvent( Event event ); • To handle an event, simply override this operation with a method. • Note the return type (boolean) that is used by the framework to decide whether or not the event was handled by the component. • If not handled, then the event is propagated to the component's container.

22. Blackbox Frameworks • Customize framework by supplying with set of components that provide application-specific behavior • Implications: • Each component required to understand a particular protocol • All or most components from component library • Interface between components defined by protocol • Need to only understand external interface of components • Less flexible • Info passed to application components must be explicitly passed.

23. Example: Event handling in Java AWT 1.0 and 1.1 • In the 1.0 version of Java AWT, event handling was implemented using inheritance. • In 1.1, this model was replaced with a delegation-based model; i.e., one that is built around protocols rather than implementation sharing.

24. Event handling (AWT 1.1) • Events are first-class objects. • There is a class Event. • Subclasses identify different kinds of events. • Components fire events. • Other objects can listen for/act upon these events. • Interested objects register themselves as a Listener with the component that fires the event.

25. AWTEvent hierarchy

26. Event routing • Lots of different kinds of events. • Different events carry different types of information. • E.g., ActionEvent carries a command, TextEvent carries a string being edited. • Components fire these events. • E.g., Button fires an ActionEvent. • E.g., TextArea fires a TextEvent. • All components fire WindowEvents. • When fired, events are routed to special Listener objects

27. Listeners • A listener is an object to which AWTEvents can be routed by components. • Different types of listeners. • One for each subclass of AWTEvent. • E.g., ActionListener, ComponentListener, WindowListener. • A listener class is abstract: • Operation names only; no attributes or methods. • Declared as an interface in Java.

28. Example: An action-event listener class ButtonListener implements ActionListener { public void actionPerformed(ActionEvent event) { System.out.println("Button pressed!!!"); } } public class ActionExample extends Applet { public void init() { Button button = new Button("Push me"); button.addActionListener( new ButtonListener()); add(button); } }

29. Example: A mouse-event listener class ButtonMouseListener implements MouseListener { public void mouseEntered(MouseEvent event) { System.out.println("Mouse entered button!"); }; public void mouseExited(MouseEvent event) { System.out.println("Mouse exited button!"); }; public void mousePressed(MouseEvent event) public void mouseClicked(MouseEvent event) {} public void mouseReleased(MouseEvent event) {} }

30. Design schema for event routing Route events of class E from graphical component C to objectO: • Design O to be an E-listener. ·Class of O must implement the E-listener interface. • ·The corresponding methods must service the event. • Add O to C's set of listeners. • Pseudo-code: C.addEListener(O);

31. Example OO Framework: Animations in the subArctic UI Toolkit

32. SubArctic and animation • SubArctic is a Java-based UI toolkit developed at Georgia Tech and Carnegie Mellon. • Powerful support for animations: • High-level model for describing time-based events in a UI. • Allows traditional image (i.e., page-flipping) animations. • Also allows objects to smoothly move about screen, modify color over time, etc. • Implemented as an OO framework.

33. Abstract UML of the framework

34. Data Dictionary • Interactor: interface defines the API that all objects appearing on the screen and/or accepting input must provide. Defines all basic operations of interactive objects • Base_parent_interactor: Base class for objects that support (arbitrary) children. Provides default implementation for all methods defined by interactor interface and supports routines • Animatable: Input protocol interface for specifying that an object is animatable. Each interactor that expects to receive animation input must implement animatable input protocol. • Anim_mover_container: A container class to move a collection of objects under control of an animation transition. • Callback_object: Interface for objects that receive callback from interactors .Callbacks are entities which are notified when significant user actions (such as a button press or a menu selection) occur. Implemented as objects in subArctic • Transition: primary abstraction for describing how animations are to proceed in subArctic. Combo of animations logical path, optional pacing function assoc. with path (does object move uniformly among values of path), animations time interval (how long does it take and when does it start) • Time_interval: first part of trajectory (absolute or relative form) • Trajectory: specifies mapping from time to a set of values (e.g., screen space) • Pacer: allow non-linear behavior for mapping

35. SubArctic animations • Animation = complex collaboration among multiple objects • interactor is the object being animated • Some classes/interfaces support customized animations • For example: • trajectory used for positional path variation (straight line, running-start, smooth curve, etc.) • pacer used for non-linear time variation • Others provide communication hooks. • Callback_object receives notifications at the beginning of the animation

36. Application Construction Environments (Toolkits) • Defn: Collection of high-level tools that allow a user to interact with an OO framework to configure and construct new applications [Johnson:joop88]. • Key observation: Easier to build a tool to specialize classes with well-defined interfaces than to build a general-purpose code generator

37. Influence of OO Frameworks

38. In-Class Exercises 1) Go over the UML diagram that describes how subArctic implements animations 2) Give them time to look over the code for a simple instantiation of the framework. 3) Ask them to construct: (a) a UML class model of the instantiation, using different colors for instantiated classes (b) a StateChart model of the entire collaboration (protocol), assuming that classes in the framework diagram denote roles in the collaboration. 4) Ask them to pair up and take a stand on the following question: Is the SubArctic animation framework an example of a white-box or a black-box framework? Why or why not?

39. Exercises • Instantiate this framework to move an object along a sinusoidal trajectory. • Extend the previous solution to make the object rotate as it is moving through time. • Question: Is subArctic an example of a whitebox or blackbox framework? Explain.