Reflection on the C

1
Unit 6

• Reflection on the C Model of Computation
  introduced so far
• the corner stones of the object-oriented model
• Why is it like this?
• We have considered modelling aspects only so far
• What else has caused the computing world to build
  a model like this?

2
Introduced so far

• Objects
• the fundamental building block of the model
• Classes
• factories that create objects
• Methods
• defined by a class to operate on objects of that
  class. May adjust internal data stored in the
  object or class, or call up operations on other
  objects
• Inheritance
• enables the reuse of existing classes in the
  construction of new classes
• Polymorphism
• enables viewing of an object in different ways

3
Modelling aspect

• This structure introduced as a result of the need
  to model the real world
• the world is made up of objects
• they are naturally classified
• the books, the chairs, the rockets, the people
• our use of objects requires us to operate on them
• we open a book book.Open()
• we ask someone their name person.GetName()
• engineering techniques
• we reuse technology as often as we are able
• e.g. a screwdriver is reused in countless problem
  solutions
• backwards and forwards compatibility
• we work with standards in the world
• they allow new and old technology to co-exist
  successfully

4
Another Motivation - Safety

• The class model brings safety
• safety a guarantee that components of a system
  operate together without damage to internal data
• for previous programmers, class safety type
  safety are synonymous
• The safety depends on the external structure of
  an object defined by its class
• its visible methods and data members
• Analogy
• Power adaptors for laptop computers are usually
  uniquely shaped to the power level they supply
• This shape (external structure) ensures that we
  don't mix the wrong supply and computer

5
Class as safety mechanism

• All objects are categorised according to the
  class that produced them
• All methods specify the class of any parameter
  objects they receive
• Hence
• Every call of a method can be checked for safety
  before execution, by
• noting the class of all parameters to the method
  in that method's definition
• checking that each parameter supplied at the call
  site is of the expected type
• If this check fails, this method call cannot run
• usually this check is performed before the
  program is executed at all, sometimes it is just
  before the call itself

6
Repercussions of class safety

• Forget all about inheritance interfaces for a
  minute
• let's see what it's like without them
• the point here is to show why we need them!
• So, an object is associated with only ONE class
• Say we have four classes
• a desk, a bicycle, a fridge and a television
• they all have a method GetWeight

7
Working with objects of different classes

• To find the weight of a collection of the four
  kinds of objects, I must treat them all
  differently adding desks, cycles etc
  independently, then adding the totals
• ie I need to write a separate code fragment for
  each kind of object to do the addition
• why? remember that code can only operate over
  objects of a single class
• This is inflexible and tedious
• additional coding for each class involved
• adding code doesn't gracefully adapt to the
  appearance of new classes

8
What is the dilemma here?

• Safe application of operations
• has been determined by a match on the whole class
  structure
• Intuitively, we notice that
• safe application only requires that the
  particular operation expected at the call site
  matches the operation available in the object
  present at execution
• Hence we could define safety on subsets of the
  whole class's structure
• which is exactly what interfaces allow us to do

9
Trust Flexibility vs Safety

• The interface requires us to trust that if many
  operations have the same name and signature
  (parameters), then they are compatible
• for example, we assume that all GetWeight methods
  are operating in the same way
• Levels of safety
• if all objects come from one class, high
  confidence that they are compatible
• if they come from a number of classes, all
  implementing one interface, we necessarily must
  be less certain
• but we've gained a level of flexibility not
  otherwise available
• Programming often involves trade-offs here is
  another

10
So why have inheritance?

• Inheritance interfaces often confused
• because the polymorphism offered by interfaces is
  also offered by classes related by inheritance
• Fundamental value of inheritance
• enables a series of classes to be related
  together according to their common parts
• common members only specified once, in base class
• can be accessed in objects of all classes derived
  from the base class
• increases efficiency of production and flexibility

11
Polymorphic aspects of inheritance

• Firstly,
• Sharing of methods is a form of polymorphic
  behaviour the code of the one common method can
  operate on objects of all derived classes
• Additionally,
• the relationship defined between objects using
  inheritance "is a" introduces the same
  fragmentation of the class as did the interface
• type safety can be specified on the base class
  only effectively, the base class is the
  interface
• no matter what additional operations the derived
  classes have, as long as we view them with base
  class spectacles, we can mix safely mix objects
  from all derived classes

12
Summary

• Reviewed the model so far
• objects, classes, methods, inheritance,
  polymorphism
• These are the defining features of the
  object-oriented model
• they separate it from the other major models of
  computation
• We now need to explore some of the other features
  of the model
• common to both the imperative and functional
  models of computation