an error by Uk4X1i68

VIEWS: 0 PAGES: 23

									 Class reuse: An OOL is     Outline for Lecture
     distinguished from one 2
     based on abstract data
                            I. Rules for
     types by                  developing
                                             reusable
         • polymorphism and                  classes
         • inheritance                       A. Finding std.
                                             protocols
       Polymorphism leads to                 B. Finding
                                             abstract classes
       the idea of using the                 C. Finding
       set of messages that                  frameworks
       an object understands             II. What makes
       as its type.1                         reuse hard?
                                             A. Argument
       Polymorphism is more                  validation
                                             B. Error handling
       powerful than the use                 C.
       of generic procedures                 Composite-object
       and packages in Ada.                     handling
                                             D. Control &
       (What is this like in                 communic.
       C++?)                                 E. Group &
                                             compound
                                                operations.
                               III. Empirical
         • A generic can be
                                    studies of
           instantiated by          reuse
           macro substitution,
                                    A. Methodology
           and the resulting        B. Results
           procedure or
           package is not at
           all polymorphic.

        • A Smalltalk object can access an
          array in which each element is of a
          different class.




1The start of this lecture is taken from Ralph Johnson and Brian
Foote, “Designing reusable classes,” Journal of Object-Oriented
Programming, 1:2, June/July 1988, pp. 22–35.


 1997 Edward F. Gehringer CSC/ECE 691O Lecture Notes, Fall 1997   18
            As long as the elements understand
            the messages being sent to them, the
            object can interact with the elements
            of the array without regard to their
            class.

     Question: To what extent does the
     preceding statement confuse
     polymorphism with dynamic binding?

     Can statically bound languages also be
     polymorphic?




Software reuse: Many reuse techniques for
    conventional languages are paralleled by
    techniques for reuse in OOLs.

        • Program skeletons are entirely
          subsumed by
        • Copying and editing a program is
          subsumed by



     What advantage does the o-o approach
     have (for documentation purposes)?




     What is the difference between black-box
     reuse and white-box reuse?




Lecture 9            Advanced Topics in Object-Oriented Systems   19
     A framework is an abstract design for a
     particular kind of o-o application.

     It usually consists of a number of classes.
     These classes can be taken from a class
     library, or can be application specific.

     MVC is an example of a framework. Is it
     a white box or a black box?




     On the other hand, a black-box
     framework can be created by supplying a
     set of components that understand a
     particular protocol.

     Then the programmer only needs to
     understand the external interface of the
     components.




 1997 Edward F. Gehringer CSC/ECE 691O Lecture Notes, Fall 1997   20
     Pluggable views are examples of this kind
     of components.



     Of black-box and white-box frameworks,
     which is easier to learn to use?

     Which is more flexible?

     Notice that in a white-box framework, the
     entire state of the instance is available to
     all the methods in the framework. Why?




     In a black-box framework, any information
     passed to constituents of the framework
     must be passed explicitly.

Rules for finding standard protocols: It is
    important for the design process to result
    in standard protocols.




     Rule 1: Recursion introduction. If one
     class communicates with a number of
     other classes, its interface to each of
     them should be the same.



Lecture 9           Advanced Topics in Object-Oriented Systems   21
     If an operation x is implemented by
     performing a similar operation on the
     components of the receiver, then that
     operation should also be named x.

     Even if the signature needs to be
     changed to add more arguments, the
     names of the new arguments should be
     similar, so that readers of the program will
     note the connection.

     Why do you think this is called “recursion
     introduction”?




     Recursion introduction can help decide
     which class to place a method in.

     Consider the problem of converting a
     parse tree into machine language.

     In addition to an object representing the
     parse tree, there will be an object
     representing the final machine-language
     procedure.

     The “generate code” message could be
     sent to either. Which should it be sent
     to?




 1997 Edward F. Gehringer CSC/ECE 691O Lecture Notes, Fall 1997   22
     Rule 2: Eliminate case analysis. It is
     almost always a mistake to check the
     class of an object explicitly. What should
     this code be replaced with?
       anObject class == ThisClass
          ifTrue: [anObject foo]
          ifFalse: [anObject fee]




     Rule 3: Reduce the number of
     arguments. Messages with more than
     about six arguments are hard to read.

     Except for instance-creation messages,
     such messages should be redefined.

     With fewer arguments, there is a greater
     chance that it will be similar to some other
     message.


     The number of arguments can be
     reduced by—

        • breaking a message into several
          smaller messages, or




Lecture 9          Advanced Topics in Object-Oriented Systems   23
        • creating a new class that represents
          a group of arguments.


     Rule 4: Reduce the size of methods.
     Methods should usually fit within a screen
     of the browser.

     Often a method in a superclass is split
     when a subclass is created.

     Most of the inherited method is correct,
     but one part needs to be changed. What
     should be done?




Rules for finding abstract classes:

     Rule 5: Class hierarchies should be deep
     and narrow. A well developed class
     hierarchy should be several layers deep.

     An obvious way to make a new
     superclass is to find some sibling classes
     that implement the same message and try
     to migrate the method to a common
     superclass.

     Perhaps a method can be broken into
     pieces, with some in the superclass and
     some in the subclass.

     For example, displaying a view consists
     of—

        • displaying its border,


 1997 Edward F. Gehringer CSC/ECE 691O Lecture Notes, Fall 1997   24
        • displaying its subviews, and
        • displaying its contents.

     All but the last can be inherited from
     View.


     Rule 6. The top of the class hierarchy
     should be abstract. Inheritance for
     generalization or code sharing usually
     indicates the need for a new subclass.

     If class B overrides a method x that it
     inherits from class A, then it might be
     better to move the methods in A that B
     does inherit to a new superclass, call it C.

                    x
                A                       C      y
                    y
                        
                x                                     x
            B                   A      x       B
                z                                     z

     B can then become a subclass of C,and
     will not have to redefine any methods.

     Rule 7: Minimize access to variables.
     Classes that access instance variables
     are more dependent on the
     representation of data.

     It is better to avoid this problem by
     sending access methods.




Lecture 9           Advanced Topics in Object-Oriented Systems   25
     Rule 8: Subclasses should be
     specializations. In the next week or two,
     we will talk about the difference between
     inheritance for specialization and
     inheritance for code-sharing.

     When inheritance is used for specializa-
     tion, the elements of the subclass can be
     thought of as elements of the superclass.

     Usually the subclass will not redefine any
     inherited methods, but will add new
     methods.

     For example, a two-dimensional array is a
     subclass of array in which all the
     elements are arrays. It might have new
     messages that use two indexes, instead
     of just one.

     An important kind of specialization is
     making an abstract class concrete, by
     “filling in the blanks” by writing methods
     not provided in the abstract class.

Rules for finding frameworks: Large classes
    are often broken into several small
    classes as they grow, leading to a new
    framework.

     A collection of small classes is almost
     always easier to reuse than a large class.




     Breaking a compiler into a parsing phase
     and a code-generation phase permits

        • a new language to be implemented
          by building only a new parser, and

 1997 Edward F. Gehringer CSC/ECE 691O Lecture Notes, Fall 1997   26
         • a new machine to be supported by
           building only a new code generator.

      Rule 10: Send messages to compo-
      nents instead of to self. An
      inheritance-based framework can be
      converted into a component-based
      framework black-box structure by
      replacing overridden methods by
      message sends to components.

      Example: Sorting routines that take
      procedural parameters.

      Rule 11: Reduce implicit parameter
      passing. Sometimes it is hard to split a
      class into two parts because methods that
      should go in different classes access the
      same instance variable.

      This can happen because the instance
      variable is being treated as a global value
      when it should be passed as a parameter.

      Changing the methods to explicitly pass
      the parameter will make it easier to factor
      the class into parts.

What makes reuse hard:2 We are still
   awaiting general “plug-compatibility” of
   modules—the ability to grow reusable
   code libraries bottom-up.

      Incompatibility among well designed but
      independently developed components
      remains a major problem for reuse.


2Lucy H. Berlin, “When objects collide: experiences with reusing
multiple class hierarchies,” Proc. OOPSLA/ECOOP ’90: Object
oriented programming languages, systems, and applications
(ACM SIGPLAN Notices ), 25:10, October 1990, pp. 181–193.


Lecture 9                 Advanced Topics in Object-Oriented Systems   27
     Here are two examples of software
     conflicts.

        • One subsystem expects the functions
          it calls to return error values,
          while another propagates exceptional
          conditions via a non-local jump (e.g.,
          longjmp in C or error throw in Lisp).
          Exceptions thrown by the second
          subsystem cause an error, since
          there is no error-handling
          environment (setjmp environment or
          catch frame) on the procedure-call
          stack.
        • User-interface management systems
          (UIMSs) and
          interprocess-communication systems
          each have separate event-handling
          loops, so that when the UIMS’s
          handler is blocked waiting for user
          events, IPC messages are not heard
          by the IPC’s handler.

     Note that—

        • Each subsystem’s architecture is
          valid individually, but
        • glue code cannot make them
          compatible.

     A fix requires breaking encapsulation and
     redesigning the internals of one or both
     modules.

     In general, there are three causes of
     conflict between software components:

        • missing code,
        • redundant code, and

 1997 Edward F. Gehringer CSC/ECE 691O Lecture Notes, Fall 1997   28
        • conflicting code.




      Berlin’s study focuses on conflicting
     code.

     The decomposition of problems into
     abstract classes disperses and
     deemphasizes control flow, and obscures
     the pragmatic decisions of a class
     hierarchy.

     Class hierarchies disperse code that
     embodies pragmatic decisions such as
     error-handling style.

     Imagine a window module with four
     classes, each of which responds to six
     mouse events.

     Testing for errors and error-handling may
     occur in each of the 24 method
     definitions, since each class

        • may have to test a slightly different
          set of arguments, or
        • may have different constraints on
          argument values.

     Would it be easy to change error-handling
     from throws to error returns?




Lecture 9           Advanced Topics in Object-Oriented Systems   29
     Berlin considers the development of a
     hypertext system written in CLOS.

     Subsystems included—

        • a “policy-free” window-system
          interface to the X-Window system,
        • a UIMS that provided customizable
          event-handlers,
        • an o-o environment kernel,
        • the PCLOS persistence extension to
          CLOS, and
        • an IPC module.

     Together they comprised

        • over 200 classes,
        • each with 20–200 methods.

     The goal was to provide a useful system
     with a full range of appropriate presenters
     and functions, not just mainline
     “proof-of-concept” functionality.

     Five pragmatic issues in component
     reuse: The major conflicts between
     component architectures occurred along
     the following five dimensions:

        •   argument validation,
        •   error handling,
        •   composite-object handling,
        •   control and communication, and
        •   group and compound operations.

     Argument validation: Argument
     validation in a user interface requires
     cooperation among many layers of an
     application.


 1997 Edward F. Gehringer CSC/ECE 691O Lecture Notes, Fall 1997   30
     For example, the command to move a link
     requires the user to indicate valid source
     and destination locations.

     There are three ways for a user to specify
     arguments:

        • declaratively (all arguments validated
          together),
        • interactively (the user gets feedback
          after each), or
        • implicitly (based on the user’s
          preferences, the operation, or the
          context).

     The appropriate interface depends on the
     application.

     But what can be done cleanly depends on
     the underlying layer’s creation style.

     The declarative style is common in
     command interfaces.

     It greatly simplifies the module’s interface,
     and can simplify validation if the
     arguments interact.

     Do you see the problem yet?




Lecture 9           Advanced Topics in Object-Oriented Systems   31
     Interactive validation requires the
     interface to know more about the
     semantics of the underlying application.

     This requires close coupling and a much
     larger surface area between the two
     subsystems.

     It was necessary to copy very low-level
     functions to provide this.

     The functions usually required complete
     recoding to be useful. Why?




     Error-handling: Error-handling is an
     inherently multi-layer activity.

     When an error is detected, it has to
     handled or passed up to another level.

     The following problems were
     encountered:
        • Passing the buck. For example, a
          window manager could not find a
          shared resource (e.g., a font), and
          returned nil, expecting that the
          enclosing creator would test for nil
          and recover.
          The UIMS expected the window
          manager to “do something
          reasonable.”
          The result was a crash with the
          message,
              “read error in ..”

 1997 Edward F. Gehringer CSC/ECE 691O Lecture Notes, Fall 1997   32
        • Not passing the buck. Sometimes
          the higher layer knew how to handle
          the problem, but wasn’t given the
          chance.
            For example, a lower layer decided to
            allocate a default color whenever a
            color wasn’t specified.
            Their application did not want that
            color, but had no control.
            The error-handling occurred within
            the body of an internal function.
            In order for the application to have
            control, the error would have had to
            have been passed up.

     Composite-object handling: Composite
     objects are structured objects whose
     elements are other objects.



     There are two styles of creating
     composite objects.

     The declarative (“outside-in”) style lets the
     developer specify a set of abstract
     choices.

     The composite is created in an
     encapsulated form, with component
     values based on the abstract choices.

     The top-down style makes inside-out
     control difficult. Requests like this
     become cumbersome:

        • “Make this button’s size be based on
          its label.”



Lecture 9             Advanced Topics in Object-Oriented Systems   33
        • “Make this browser large enough to
          handle the number of elements.”

     The interactive (“inside-out”) style exports
     creators for each of the elements, then
     builds the composite once the elements
     have been constructed.

     So a browser can be laid out based on
     the widths of its elements, etc.

     Since the elements are created first, it
     becomes more cumbersome to specify
     common attributes among components
     (such as colors and fonts).

     Berlin’s project ended up using a hybrid
     control style, which required redesign of
     both layers.

     Control and communication: [Due to lack
     of time, read the paper.]

     Group and compound operations:
     Operations like “delete these five items,”
     or “move text and links within this region”
     proved difficult to implement.

     The problems were caused by
     encapsulation at the “wrong” level, but the
     “right” level was not possible to foresee.

     Consider a simple operation to delete
     nodes N1 and N2 from a collection.

     They had a “delete node” operation.

     “delete nodes” should just have required
     calling “delete node” repeatedly.

     But side-effects got in the way.


 1997 Edward F. Gehringer CSC/ECE 691O Lecture Notes, Fall 1997   34
     Consider the implementation of “delete
     node.”

     1.     Open a transaction to the database.

     2.     Recache and lock a group of objects
            (the node, its links, neighboring
            nodes), and the enclosing collection.

     3.     Delete the node, links, and
            link-anchor information from the
            adjacent nodes.

     4.     Save the changes to the database.

     5.     Commit the transaction, unlocking
            the objects.

     6.     Notify the presenters of the nodes,
            and notify the collection.

     What’s wrong with repeating this for each
     node to be deleted?

     1.




     2.




Lecture 9             Advanced Topics in Object-Oriented Systems   35
     3.




Empirical studies of class reuse:3 Lewis et al.
   designed a controlled experiment to
   measure the relative effects of a
   procedural language and an o-o language
   in terms of software reuse.

     The subjects were a set of senior-level
     software-engineering students. They
     developed a system to “computerize” a
     fictional company, and consists of two
     tasks.

     The phases of the research are
     diagrammed on the next page.




               Lewis et al., Figure 1, p. 36.




     During Phase 1, two sets of potentially
     reusable components were developed.

          • One set was developed in Pascal.
          • The other set was developed in C++.




3Lewis, John A.; Henry, Sallie M.; Kafura, Dennis G.; Schulman,
Robert S., “On the relationship between the object-oriented
paradigm and software reuse: an empirical investigation,”
Journal of Object-Oriented Programming, 5:4, July/August 1992,
pp. 35–41.


 1997 Edward F. Gehringer CSC/ECE 691O Lecture Notes, Fall 1997   36
     During Phase 2, independent subjects
     were required to implement the target
     project using the sets of components.

     The subjects were divided into six groups,
     as shown below. For each language,

        • some programmers were forbidden to
          reuse anything written in Phase 1,
        •    another group was allowed to reuse,
            and
        • a third group was told to reuse
          anything that was remotely
          appropriate.

     The experiment was controlled in various
     ways; see the paper.

     The main productivity measures are
     these:

        • Runs—the number of runs made
          during system development and
          testing.
        • RTE—the number of runtime errors
          discovered during system
          development and testing.

     The secondary productivity measures
     were these:

        • Edits—the number of edits performed
          during system development and
          testing.
        • Syn.—the number of syntax errors
          made during system development
          and testing.




Lecture 9            Advanced Topics in Object-Oriented Systems   37
     High values correspond to low
     productivity.

     Results are shown below.




             Lewis et al., Figure 3, p. 38.




     As the table below shows, main
     productivity measures were better for the
     groups using the o-o language.

                       Language main effect

                                               Means

                Signif-                Proced-      O-O No
                           p-value       ural
                icant?                               reuse
                                          No
                                        reuse
       Runs      Yes       0.0066         59.27        47.50
       RTE       Yes       0.0078         65.00        50.20



 1997 Edward F. Gehringer CSC/ECE 691O Lecture Notes, Fall 1997   38
        Time      Yes       0.0104       354.41        261.70
        Edits      No       0.3469       271.55        263.65
        Syn.       No       0.8675       183.67        202.40

     However, this effect shows up only when
     reuse is allowed:

            No reuse (procedural vs. object-oriented)

                                                 Means

                 Signif-                 Proced-      O-O No
                            p-value        ural
                 icant?                                reuse
                                            No
                                          reuse
        Runs       No       0.8909          75.38        83.17
        RTE        No       0.7506          81.25        87.17
        Time       No       0.1607       446.38        385.00
        Edits      No       0.2360       416.00        392.00
        Syn.       No       0.1733       311.00        290.33


            Reuse (procedural vs. object-oriented

                                                 Means

                 Signif-                 Proced-      O-O No
                            p-value        ural
                 icant?                                reuse
                                            No
                                          reuse
        Runs      Yes       0.0001          50.07        33.21
        RTE       Yes       0.0005          55.71        34.36
        Time       No       0.0153       301.86        208.86


Lecture 9               Advanced Topics in Object-Oriented Systems   39
       Edits      No       0.8380       189.00       208.64
       Syn.       No       0.0868       137.14       164.71




 1997 Edward F. Gehringer CSC/ECE 691O Lecture Notes, Fall 1997   40

								
To top