This document discusses object design in object-oriented programming, emphasizing the importance of class responsibilities, cohesion, and coupling. Key principles include using inheritance and composition effectively, conducting natural language analysis to identify candidate classes, and the significance of incremental development. The document highlights the complexities of object-oriented design and stresses the importance of simplicity and early compilation in the development process.

1. Object Design
Michael Heron

2. Introduction
• In this lecture we are going to round off our discussion about
object orientation with some points about object design.
• Designing good object oriented programs is not simple.
• Object orientation is not a particular focus of the module.
• Important however you recognise it when you see it.

3. Class Design
• Several important principles when designing classes.
• Classes should have one responsibility only.
• This leads to high cohesion.
• Classes should have the minimal number of connections to other
classes.
• Not zero connections, that doesn’t work.
• Classes should expose only those parts of their functionality that
are part of the interface.

4. Visibility
• Variables should always be private.
• There is never a good reason for them not to be.
• Other methods should be:
• Private if they are entirely internal functions.
• Public if they are to be used by anyone.
• Protected if you can’t get away with making functions private.
• Protected is a special level of visibility dealing with inheritance.

5. Object Orientation
• Object oriented programs are not inherently scalable.
• If you are not careful, they become difficult to manipulate beyond
about 10/15 classes.
• Important to design object oriented programs correctly.
• Need a way to measure the quality of an OO design.
• Two metrics used for this.

6. Cohesion
• Cohesion is the degree to which a class adheres to a single
responsibility.
• Very important for good class design.
• Good object oriented programs have highly cohesive classes.
• They do one thing, and one thing only.
• If necessary, classes should be refactored to ensure this.
• Modify the internals of the class, breaking it out into multiple
classes where appropriate.

7. Coupling
• Coupling defines the degree to which classes are connected
together.
• Lower coupling is best.
• Trade off exists here – lowering coupling involves lowering the
cohesion of classes.
• Increasing cohesion means increasing the coupling of classes.
• Must decide on a balance for each individual program.

8. Object Orientation and
Inheritance
• One of the most powerful tools available in object orientation
is that of inheritance.
• It allows us to bundle functionality together and share it between
multiple objects.
• Whenever you have objects that have similar
roles/responsibilities, consider making use of inheritance.
• Many benefits come from this.

9. Inheritance
• Object oriented programs that make use of inheritance are, in
general:
• Easier to debug
• Easier to maintain
• Easier to reuse
• Quicker to write
• Use inheritance to express ‘is-a’ relationships in your code.
• Even if there is no immediate need, it’s worth considering for the
sake of ‘future proofing’.

10. Composition
• It’s quite common for objects to make use of other objects.
• In fact, it’s a big part of object orientation.
• This is called composition.
• It’s sometimes difficult to express when things should be an
inheritance and when it should be expressed as composition.
• Composition models a has-a relationship.

11. Deciding On Objects
• Working out which objects you want to incorporate into a
program can be a complicated affair.
• There’s no hard and fast rule about what an object actually is.
• Worthwhile to make use of some kind of heuristic system.
• Such as ‘natural language analysis’.

12. Natural Language Analysis
• Take a requirements brief.
• Such as an assessment exercise.
• Identify all the nouns
• These are your candidate classes.
• Identify all the verbs
• These imply methods
• Identify all the adjectives
• These suggest the existence of attributes.
• Make special note of relationships expressed in the text.
• These model inheritance and composition relationships.

13. Natural Language Analysis
• The idea is not to derive an exact model of the program.
• Only to give some inspiration.
• Much thought is needed to extract useful information.
• Written language, particularly if it scans well, is not very precise.
• Written language contains a lot of repetition and synonyms.
• The information you extract is candidate information only.

14. Designing an Object
• Designing an object works much in the same way as incremental
development.
• Start small, with a minimal representation.
• Add the methods that let you act upon that representation.
• Expand on this functionality as needed.
• Object orientation introduces new complications when it comes to
writing programs.
• Especially important to start small.

15. Designing an Object
• The architecture of an object oriented program is made up of
several things.
• The classes that exist in the program.
• The interface those classes present to others.
• The communication between objects
• Modeled as method calls
• Important to think of the context of objects.
• What are they supposed to do
• What objects should they be calling upon?

16. Example Process
• Given a scenario:
• The People Who Hate People bank are looking for someone to write
a software system for them. The system should permit the modeling
of several accounts and the owners of those accounts, allowing them
to deposit, withdraw, and view their balances. Accounts have
numbers that identify them, and owners have their name and
address stored in the system. The system should provide an interface
that allows users to interact with the application.
• How do we arrive at the classes?

17. Example Process
• First we use natural language analysis to identify all of the
different parts of the system.
• This gives us our candidate list.
• Then we analyse this list to derive the list of classes we are
going to write.
• This won’t be all of them.
• Some will be synonyms.
• Some will be better handled as attributes of another class.
• Some will be irrelevant.

18. Example Process
• Having gotten a list of viable candidates, consider their
relationship.
• A UML diagram is a good way to do this.
• Consider what data they must represent.
• Consider what interface they must present.
• Keep it simple to begin with.
• It’s easy to expand later as needed.
• It’s not so easy to scale back later.

19. Example Process
• Having gotten the plan down, create skeletons of the classes.
• A header and a CPP file for each class.
• Create the definition, don’t worry too much about the
implementation to begin with.
• Design them as if they were black box systems.
• Compile early and often.
• Don’t wait until they do something interesting before you
compile them.

20. Placeholder Methods
• An important part of software design is abstraction.
• Not worrying about the details until you have sorted out the big picture.
• One good way in which this is done is the writing of placeholder
methods.
• You don’t need to actually make methods do something.
• You just have to have them there in the right structure.
• Make abundant use of these in your code.
• Even if all they do is print to the screen ‘This method was called’.

21. Compile Early, Compile Often
• Object orientation in particular opens up a new family of
problems with compiling code.
• Mostly in terms of what are known as linker errors.
• These are errors in what you have told C++ the class should be
(in your .h file) as opposed to what it actually is (in your .cpp
file).
• Compiling early will indentify these problems before they are
too time-consuming to fix.

22. Compile Early, Compile Often
• Focus on getting only the simplest core functionality in place.
• Represent data
• Provide accessors for that data
• Once you have that simple representation, build on it.
• Add in methods that allow you to manipulate the data
representation appropriately.
• Compile and test after every new piece of functionality.

23. Summary
• Object design is tricky
• As is working out what objects you want to represent in a
program.
• There are several guidelines that can help.
• But it’s mostly going to come from practise.
• Object orientation introduces new complexities with coding.
• It’s important to manage these with incremental development.