Introduction to OO Design

1
Introduction to OO Design

• Use criteria for evaluating classes
• Assess whether the right methods are provided
• Assess the parameters results of the methods
• Explain the use of exceptions
• Distinguish between
• Homogenous and heterogeneous collections
• Reference and value semantics
• Discuss implementation of collection classes

2
The Interface to a Class

• Interface for a programmer using an object
• Desirable Features
• Easy to use
• No need to understand implementation details
• Cant break semantics (That is, no cheating)
• Efficiency
• Interface for the writer of a descendent class
• Desirable Features
• Flexibility
• Create any plausible extensions
• Efficiency

3
Design Criteria

• Note criteria can be inconsistent have to use
  judgement
• Coherence
• Class describes a single abstraction.
• Coupling
• Well-defined, simple, enforced interfaces
• Use Primitive Operations
• Operations should not be decomposable.
• e.g. bool ListAdvance(item i) ?
• bool ListAtEnd() ?
• void ListCurrent(item ip) ?
• void ListNext() ?
• Completeness
• All operations making sense on the abstraction
  are supported.
• list operations without remove ?
• mathematical operations without minus ?

Move to the next item, set i to the value, return
true if its the last item
4
Design Criteria 2

• Consistency
• Adopt a common convention for
• Names
• Arguments and Return Values
• Order of parameters
• Representation of information, e.g.
• return true on success, false on failure
• specify slice of array by start and length
• Behaviour e.g. number of first item of array
• Convenience (Secondary)
• Include operations supporting normal patterns of
  use.
• e.g. void stringgetword (...)

Or by start and end pointers Or by start and end
1 pointer
Be consistent!
5
Reviewing an interface

• Interface design crystallises through use
• Adjustments are made from experience
• Questions to ask
• Too many operations?
• ensure operations related to single abstraction
• are all operations really used?
• Too many ways to do a single task?
• Reusability
• if class is definitely single use, don't
  over-generalise
• simplicity aids reuse
• Dependencies
• minimise dependencies on other classes
• e.g. don't handle output, prepare data in
  standard form

6
Exceptional Situations

• Inherent possible errors are part of an interface
• e.g.
• Inherent errors for integers
• Divide by zero, overflow
• Inherent errors for stacks
• Pop from empty stack, push on full stack
• Define error handling when defining interface
• Identify error/exceptional situation
• Define error-handling protocol
• Return error result
• Additional error parameter
• GetError function
• Exceptions

7
Exceptions

• Define Behaviour in Abnormal Conditions

class EMyError public exception char
message EMyError (char info) //
initialisation try if (x/ygt1000) throw EMyError
("exit with error") catch(const EDivByZero
E) // catch hardware exception // do
something catch(const EMyError E) // catch
own exception catch(...) // catch any other
exception
Yes, is part of the syntax of C, not me
indicating that something has been left out
8
Benefits of Exceptions

• Allow separation of normal from error processing
• Allow flexible error-handling
• Provide default error-handling
• Enforce error-handling
• Java checks that exception handlers are provided
• But
• Some additional overhead at run-time
• Can be over-used
• Should only be used to handle exceptional
  conditions

9
Collection/Container Classes

• An example of a hierarchy and interfaces
• Represent / contain groups of objects
• e.g. file collection of lines
• line collection of words
• Homogeneous Collections
• All objects of same type
• Heterogeneous Collections
• Different types, but usually have common ancestor
• Kinds of Collection
• array, list, set, bag, queue, deque, stack, file

10
Expected Methods

• add, delete, processItems, isEmpty, and ?
• processItems is an interator
• An iterator can be used
• to 'get the next item' in a collection
• to apply an operation to each item
• Questions
• Will all collection classes provide the same
  interface?

11
Smalltalk Collections
12
STL Containers

• Sequences - ordered
• Select by complexity of operations over life of
  application
• Vector (Dynamic Array, Use by default)
• List (Bi-directional Sequential Access)
• Deque (Optimised for add/remove at start or end)
• Associative containers not ordered
• Set (item present / not present)
• Multiset ( a Bag, item present multiple times)
• Map (key -gt target)
• Multimap (key -gt targets)

If a collection is ordered, must it be
sorted? No, ordered means there is a first, a
second, It says nothing about the size of the
items.
If a collection is ordered, must it be
sorted?
13
Implementation Issues

• Efficiency
• Speed
• Memory requirements
• Flexibility
• heterogeneous / homogeneous
• Dynamic/static capacity
• re-use
• Error handling
• Error results
• Exceptions

14
Options Types

• Use native pointers
• Efficient
• Lack of error checking / need for casts
• Use common ancestor as element
• Can rely on common properties
• e.g. equality test writing to stream (file)
• Use of templates / generics (C / C, Java)
• Good error checking
• No need for run-time type checks / casts
• Potentially very efficient

15
Options Semantics Structure

• Value vs. Reference Semantics
• Value
• Collection contains a copy of the data
• Copy is destroyed if the collection is destroyed
• Reference
• Collection contains a pointer to the data
• Instance of data remains if the collection is
  destroyed
• Underlying Data Structure
• Linked list
• Array
• Array with reallocation when size limit reached

16
Summary

• Interfaces to objects must be defined carefully
• Visible methods
• Parameters and results
• Conflicting criteria for evaluating object
  interfaces
• Collection class
• Represent a group of objects
• Various design decisions
• Heterogeneous or homogenous
• Reference or value semantics