ICS312 Object Oriented Programming

1
ICS312 Object Oriented Programming

• Lecture 4
• Dr. Ken Cosh

2
Review

• Relationships
• Between Objects
• Links
• Aggregation
• Between Classes
• Association
• Inheritance
• Aggregation
• Using
• Metaclass

3
This Week

• Actually doing it!
• How to make quality Abstractions.
• Choosing Operations
• Choosing Relationships
• Choosing Implementations
• How to Classify things.
• Behavioural Analysis
• Domain Analysis
• Use Case Analysis
• Structured Analysis

4
Approach

• 1) Identify the classes and objects that form the
  vocabulary of the problem domain.
• 2) Invent the structures whereby sets of objects
  work together to provide the behaviours that
  satisfy the requirements of the problem.
• But how do we do this well?

5
What is a good abstraction?

• A system should be built with a minimum set of
  unchangeable parts those parts should be as
  general as possible and all parts of the system
  should be help in a uniform framework (Ingalls)
• Object development is normally incremental, with
  objects evolving into good objects. But, for
  maintainability, understandability, integrity
  reasons, the first attempt should be as close as
  possible to the final version.

6
Metrics

• As suggested by Booch
• Coupling
• Cohesion
• Sufficiency
• Completeness
• Primitiveness

7
Coupling

• The measure of strength of association between
  modules (or rather objects).
• With weak coupling, complexity is reduced (as
  objects can easily work alone)
• But, inheritance introduces a strong coupling
  which exploits the commonality between
  abstractions.

8
Cohesion

• Cohesion refers to the relationships between
  objects in a module.
• It is not ideal to have a coincidental module
  comprising of classes for dogs and spacecraft.
• Better is functional cohesion, where elements
  work together to create some well bounded
  behaviour
• A good dog class is one that defines the
  behaviour of a dog, a whole dog and nothing but
  the dog!

9
Sufficient

• Sufficiency reflects that a class should contain
  at least all the minimal functionality.
• A class to contain a set of data is useless
  without an add function.

10
Complete

• Contrasting sufficient, completeness reflects a
  class that contains all of the aspects of the
  abstraction.
• While sufficiency represents a minimal interface,
  completeness represents a thorough interface.

11
Primitive

• There is a trade off between Sufficiency and
  Completeness, which is countered by
  Primitiveness.
• To be complete perhaps we should include a
  function Add4, which adds 4 elements.
• This is not primitive though!

12
Choosing Operations

• When choosing the operations to include in an
  abstraction, the arguments of Sufficient,
  Complete, yet Primitive, should be
  remembered.
• Yet, there are still many choices for how to
  break down operations.
• Clumping some behaviour together into 1 method
  results in a simple interface, but a complicated
  method.
• Breaking said behaviour between multiple methods
  results in a complicated interface, but simple
  methods.

13
Choosing Operations

• As classes evolve, it is often easier to simply
  create a new subclass that inherits from the
  original class with new functionality added.
• A good designer knows how to find the
  appropriate balance between too much contracting,
  which produces fragmentation, and too little,
  which yields unmanageably large modules. (Meyer)

14
Choosing Operations

• Metrics
• Reusability
• Would this behaviour be more useful in more than
  one context?
• Complexity
• How difficult is it to implement the behaviour?
• Applicability
• How relevant is the behaviour to the type in
  which it might be placed?
• Implementation Knowledge
• Does the behaviours implementation depend upon
  the internal details of a type?
• (Halbert OBrien)

15
Choosing Relationships

• How should the class CAR be related to the
  class WHEEL should it be inheritance?
  containment? using?
• I would suggest aggregation
• Inheritance is appropriate if every instance of
  B may also be viewed as an instance of A. The
  client relationship is appropriate when every
  instance of B simply possesses one of more
  attributes of A (Meyer).

16
Choosing Implementations

• Having chosen appropriate classes and their
  appropriate relationships, we also need to
  consider the implementation.
• Suppose we have a class CONE and suppose on
  occasion we need to know the volume of the cone
• Should we implement a function Volume()?
• Or have a attribute Volume?
• How do you make this decision?
• What if you are more concerned about Space?
• What if you are more concerned about Time?

17
The Perfect Class Structure

• So, weve discussed some things to consider, but
  how do we create the perfect result?
• Its a Holy Grail, there is no panacea
  (Stroustrup)
• Thats a fundamental question for which there is
  no easy answer. I try things. (Gabriel, co
  designer of CLOS)

18
Classification

• An omnipresent problem in science is to
  construct meaningful classifications of observed
  objects or situations. Such classifications
  facilitate human comprehension of the
  observations and subsequent development of a
  scientific theory. (Stepp)
• For an architect, his act of design, whether
  humble or gigantically complex, is governed by
  the patterns he has in his mind at that moment,
  and his ability to combine these patterns to form
  a new design (Alexander)

19
ICH113 Chemistry

• In olden times, all substances were thought to be
  a combination of Earth, Air, Fire and
  Water.
• An interesting classification!
• In 1789, Lavoisier published a list of 23 items.
• Some of these turned out not to exist.
• In 1869, Mendeleyev proposed the periodic law,
  which listed many elements, some of which hadnt
  been found yet.
• In the early 1900s, atomic weights were
  discovered leading to further classification with
  isotopes of elements.
• Who wishes they could have taken ICH113 500 years
  ago? What will it be like in another 500 years?
• Computing (and OOP) is a very new field, so how
  can we pick appropriate classifications?

20
Evolutionary Classification

• Involving Derivation
• Deciding to create new subclasses from existing
  ones.
• Factorisation
• Breaking a large class into several smaller ones.
• Composition
• Creating a larger class by combining smaller
  ones.
• Abstraction
• Discovering a new commonality and creating a new
  class.

21
So, the perfect classification?

• Doesnt exist!
• And everyone will have a different perspective on
  what is might be anyway
• Why is a goldfish like a laserbeam? Because
  neither can whistle!

22
Approaches to Classification

• There are 3 key approaches to classification
• Classical categorisation
• Conceptual clustering
• Prototype theory

23
Classical categorisation

• All the entities that have a given property or
  collection of properties in common form a
  category. Such properties are necessary and
  sufficient to define the category. (Lakoff)
• Married people forms an easy category, tall
  people is more ambiguous without absolute
  membership criteria.

24
Classical categorisation

• Originates with Plato
• He classified plants and animals based on the
  answers to questions like Does it have fur or
  feathers?
• Young children use this approach, where after the
  ago of 1, typically children understand object
  permanence which directly leads to developing
  classifying skills
• Dog! Tree! Cat!
• Later they develop generalisation (Animals!), an
  specification (Beagle!)

25
Classical categorisation

• Natural categories tend to be messy Most birds
  fly, but some do not. Chairs can be made of
  wood, plastic or metal and can have almost any
  number of legs, depending on the whim of the
  designer. It seems practically impossible to
  come up with a property list for any natural
  category that excludes all examples that are not
  in the category and includes all examples that
  are in the category. (Kosok)

26
Conceptual clustering

• This approach is very akin to fuzzy set theory,
  where objects belong to groups in varying degrees
  of fitness.
• A probabilistic clustering of objects.
• Absolute judgements about classification come
  from best fit.

27
Prototype theory

• Wittgenstein pointed out that a category like
  game does not fit the classical mold, since there
  are no common properties shared by all games
  Though there is no single collection of
  properties that all games share, the category of
  games is united by what Wittgenstein calls family
  resemblances Wittgenstein also observed that
  there was no fixed boundary to the category game.
  The category could be extended and new kinds of
  games be introduced, provided that they resembled
  previous games in appropriate ways. (Lakoff)

28
Prototype theory

• We understand beanbag chairs, barbers chairs
  and contour chairs as being chairs, not because
  they share some fixed set of defining objects
  with the prototype, but rather because they bear
  a sufficient family resemblance to the prototype
  There need be no fixed core of properties of
  prototypical chairs that are shared by both
  beanbag and barber chairs, yet they are both
  chairs because each in its different way, is
  sufficiently close to the prototype.
  Interactional properties are prominent among the
  kinds of properties that count in determining
  sufficent family resemblance. (Lakoff and
  Johnson)

29
Where are the objects?

• Tangible things
• Roles
• Events
• Interactions
• People
• Places
• Things
• Organisations
• Concepts
• Events
• Structures
• Devices

30
How do we get them?

• Behavioural Analysis
• Domain Analysis
• Use Case Analysis
• English Description

31
Behavioural Analysis

• The approach we use emphasises first
  understanding what takes place in the system.
  These are the system behaviours. We next assign
  these behaviours to parts of the system and try
  to understand who initiates and who participates
  in those behaviours Initiators and participants
  who play significant roles are recognised as
  object and are assigned the behavioural
  responsibilities for these roles. (Rubin
  Goldberg)

32
Domain Analysis

• An attempt to identify the objects, operations
  and relationships that domain experts perceive to
  be important about the domain (Neighbors)

33
Use Case Analysis

• A use case is a particular form or pattern or
  exemplar of usage, a scenario that begins with
  some user of the system initiating some
  transaction or sequence of interrelated events
  (Jacobson)
• Use cases / scenarios can be used to work through
  the interacting elements in a system.

34
English Description

• Take an english description of the problem, and
  identify the nounds and verbs. Nouns are likely
  to represent candidate objects and verbs
  represent operations on them.

35
Evolution

• Again, it is likely that an element of evolution
  is necessary before the final object model is
  created. We may begin with some objects, which
  we feel may be related, and from them form some
  generalisations, or specialisations to evolve an
  object model.