CS 381

1
CS 381

• OOP - Part 1
• OOP and reuse

2
Goal of Software Reuse

• Noted as far back as 1968
• Why cant CS use interchangable parts, like other
  engineering fields
• Problem What are interchangable parts for
  software?
• Or, how do you do software reuse??

3
Earliest reuse functions

• The oldest and simplest form of reuse the
  subroutine (function, procedure)
• Works great for math libraries, I/O, many other
  areas
• Still the heart of any type of reuse

4
Problems with functions

• Low level. Application is still written from
  scratch on top of the libraries
• Functions do not have any memory
• Many tasks require a number of functions working
  together (e.g., a stack)

5
The problem of the stack

• Think of a language with two scope levels
  (Fortran, old style C)
• Imagine you are writing a stack
• Where does the data live?
• Cant be local, must be global, defeats
  encapsulation

6
Better encapsulation

• Need an encapsulation mechanism that is larger
  than a simple function
• Idea the module
• Basically, a package for functions and data
• Import/export list to control what flows into and
  out of the module

7
Parnas Principles

• The designer of a module needs access to the
  minimal amount of information required to do the
  job, nothing more
• The user of a module needs access to the minimal
  amount of information to access module
  operations, nothing more
• Basis for all rules of encapsulation

8
Modules on top of modules

• A module is providing a service
• One module can make use of the services provided
  by another
• This is a slight improvement in software reuse -
  idea of composition

9
Problems with module

• No easy way to make multiple instances
• Still doesnt feel quite like an interchangable
  part

10
ADT movement

• Abstract Data type
• Defined by operations, not by implementations
• Can make multiple instances
• How to separate interface from implementation?

11
One idea

• Two types - interface type and implementation
  type
• Polymorphic assignment
• Declare a variable as interface
• But give it a value from an implementation

12
Problems with interface

• Type checking rules - separation between declared
  type and type of value it is holding
• Implications for memory management - how much
  space for an interface??
• Implications for execution - how to match a
  function call to code

13
Binding times

• Remember the idea of binding times?
• Issue when should following be bound?
• Size of a variable
• Code to be executed for each operation
• Compile time binding is more efficient, run-time
  binding is more flexible, which goal is more
  important?

14
Memory management

• Either force the programmer to select an
  implementation at compile time (when sizes are
  known)
• Or use more expensive heap memory
• Many languages experimented with both these
  alternatives

15
Virtual Method tables

• Functions in an interface are assigned index
  values into a table
• Each implementation provides table of pointers to
  code
• Each value holds a pointer to its VMT

16
What is OOP??

• Viewed one way, OOP is simply ADT message
  passing Inheritance
• Message passing - a way to do late binding
• Inheritance - a way to address software reuse

17
Message Passing

• Make one argument special (the receiver)
• The receiver determines what a message means
• A natural way to explain late binding
• Implemented using VMTs

18
Object-based languages

• Yes, you can almost do OO without inheritance
• Just have interfaces, message passing
• Called object-based language

19
But what about reuse??

• Late binding is useful, but didnt really address
  original issue - how to do software reuse
• Solution Inheritance. Create a new type that is
  a specialization of an existing type

20
Inheritance - specialization

• Very similar to categorization used in everyday
  life
• Genus/speces/phylum
• Just another type of categorization.
• Easy metaphor to explain and use

21
Children and Parents

• A child class gets all the data fields from the
  parent
• A child class gets all the functions from the
  parent
• Can add new functions
• Can override inherited functions
• Combine with polymorphic assignment

22
A new type of reuse

• Combining inheritance and overriding provided a
  new type of reuse
• Specialization New type is a more specialized
  version of existing type
• E.g.a checking account is a more specialized
  version of bank account, a button in a more
  specialized version of graphicalcomponent.

23
Inheritance of code /inheritance of concept

• A child class can get specific code from the
  parent - inheritance of code
• A child class can fill in a specification
  defined by the parent - inheritance of concept
• Used together create something new

24
Frameworks

• Some general purpose code defined in parent, but
  specialized in the child class
• E.g., GUI framework, can manage windows, leave it
  to child class to figure out how to draw window
  or what mouse down means

25
Reconcile reuse and specialization

• Frameworks address one fundamental problem of
  reuse
• How do you make general purpose components and
  still
• Specialize them to work in a new situation

26
Upside down library

• OOP permits an UPSIDE/DOWN library (I.e., GUI
  system)
• The Framework is in control, calls new code for
  various functions
• In traditional library, main program is new,
  calls procedures for reuse

27
Finally! True reuse

• For a short time, wild enthusiasm that OOP had
  finally solved the problem of reuse
• Problems
• Designing reusable components is hard
• Who pays for it?
• While it works at one level, problems keep
  getting bigger

28
So, is OOP the last word?

• Certainly not.
• Still lots of lessons to be learned from
  functional community (e.g., the STL)
• Generics - another type of reuse
• How to reuse more ambiguous design issues -
  pattern movement
• Components, distributed computing

29
Want to learn more??

• Buy the book -)
• Or take CS 582 (fall term)