2CPP05 - Modelling an Object Oriented Program

MODELING AN OBJECT ORIENTED PROGRAM Michael Heron

Introduction • In this lecture we are going to take a little detour into the world of UML. • A small detour, to support us in later weeks. • UML is a language of diagrams and syntax designed to communicate the intention and design of object oriented programs. • For our purpose, we are going to discuss only one part of it. • The Class Diagram

Class Diagrams • One of the reasons why software development has such a complex vocabulary of jargon is the need for experts to communicate succinctly. • This is what all formal software design techniques are about. • It is extremely useful when we talk about the design of objects for us to have some kind of shared vocabulary. • Hence the introduction of this diagram.

Class Diagrams • You won’t be expected during this module to be able to break complex problems down into objects and classes of your own. • You’ll learn more about that in third year. • All I would like of you with relation to class diagrams is that you can read them and interpret them. • And at a push, write up your own.

Object Oriented Programs • Object oriented programs introduce new complexities of interaction. • Objects have a relationship to classes. • Objects may be composed of other objects. • Objects define their own behaviours and attributes. • Objects can offer several levels of indirection to other objects. • Gaining a clear perspective on how an object oriented program fits together is key to developing and maintaining OO code.

Object Relationships • Objects can contain references to other objects. • This is known as composition. • This is a has a relationship. • Composition relationships also imply a multiplicity (or cardinality). • Where there is a 0 or 1 relationship, it is known as a composition. • Where it is more, it is an aggregation. • Formal UML notations have more precise differentiations of composition.

Object Relationships • An object may be a specialisation of another object. • This is known as inheritance in object orientation. • This is a is a relationship. • More specialised forms of inheritance exist. • We’ll talk about these as we go along. • For now, we will look only at the case that a class can inherit the properties of another in their entirety.

Examples • A Car: • Has an engine (composition) • Has four wheels (aggregation) • Has 2 or more doors (aggregation) • Is a vehicle (inheritance) • A Cat: • Has four legs (aggregation) • Is an animal (inheritance) • Has a tail (composition)

Object Oriented Programs • The relationship between objects and classes becomes very complex in many computer programs. • Some means of representing this complexity ‘at a glance’ is useful. • This is what a class diagram is used for. • It gives the static view of a program’s architecture. • Other techniques exist too. • They vary in effectiveness.

Class Diagrams • At their simplest, class diagrams are just boxes with lines connecting them to other boxes. • They show the relationship between classes only.

Class Diagrams • At the next level of usefulness, class diagrams also contain information about attributes and methods. • Attributes in the second row • Methods in the third • At their best, class diagrams contain class relationships, methods, attributes, and the visibility of each. • They also explicitly show multiplicity.

Why Use A Class Diagram? • There are several reasons why usig a class diagram leads to a more complete view of a project. • It shows the relationship between classes in a way that allows you to trace accessibility. • It shows at a glance the amount of coupling in a project. • It shows at a glance the amount of cohesion in a project. • It shows at a glance the impact of change.

Coupling and Cohesion • One of the biggest problems OO developers have is ensuring a good OO design. • What is a good OO design, you ask? • Certainly for people unfamiliar with how OO is best done, it’s hard to objectively rate an object architecture. • Two objective measures exist for this though. • As a rule, we are aiming for high cohesion and low coupling.

Coupling • Coupling relates to the amount of interconnectedness of classes. • We want this to be as low as is reasonably possible. • A coupling relationship is any composition, aggregation, or inheritance. • The more connections made between objects and classes, the harder it is to make any changes. • Because of the knock-on effect associated.

Coupling • If your program has high coupling, there are several disadvantages built in: • Changes in one object may result in unexpected side-effects elsewhere in a program. • Often the cause is not at all obvious. • Classes are difficult to understand at a glance. • They make use of so much external functionality. • Classes are difficult to test. • They cannot be easily extracted from their context.

Coupling • There are several types of coupling that exist. • It’s not just the amount of coupling that matters, but also the type of coupling. • Content coupling is when one class directly accesses data local to another class. • This is terrible and should be avoided always. • Data coupling is when a public interface is used to exchange to exchange parameters. • This is better. • There are other kinds. • We don’t have to go into them to any great degree for now.

Cohesion • Cohesion is the level to which an object adheres to a single set of responsibilities. • We want this as high as is reasonably possible. • In a good object oriented program, each object has one firmly defined responsibility. • If you have a BankBalance class, it should contain only the functionality for manipulating the balance. • It should not contain, for example, the address of its owner.

Cohesion • The dangers that come from low cohesion are the same as that of high coupling. • They’re really just two ways of reflecting the same basic concept. • Low cohesion is an insidious problem. • Programs with low cohesion tend to become even less coherent over time. • It is a consequence of badly analysed and badly designed programs. • You’ll learn how to do this properly in third year.

The Tension of OO Development • Object Oriented programs are a tension between coupling and cohesion. • We increase cohesion by increasing coupling. • We reduce coupling by decreasing cohesion. • As OO developers we have to find a happy medium between the two. • In some cases, simple rationalisation of a design can remove problems.

Impact of Change • Both of these concepts are a way of objectively rating the impact of change in a program. • What makes a program easy to work with? • Clearly written code. • Comments (seriously) • Changes do not have unexpected consequences. • The latter of these three is what the impact of change defines.

Impact of Change • One of the reasons we restrict visibility of variables and methods is to manage the impact of change. • If you are a Respectful Developer, you avoid making changes that will impact on code you did not write. • Lest terrible vengeance be visited upon you and your kith and kin • The lower the visibility, the better. • Changing a private variable for example only impacts the class in which it is defined.

Impact of Change • In a multi-developer environment you have to assume that if functionality is available, it has been used. • Someone saw your calculate_awesome() method and thought ‘hey, that does exactly what I want’ • If it can be used, you can’t idly make structural changes. • Refactoring is fine • Redesign is not

The Class Diagram • The best quality of class diagrams shows the impact of change at a glance. • Where there are lots of arrows, there be coupling issues. • Where there are huge lists of methods and attributes in a class, there be likely cohesion problems. • Where there are lots of public methods and attributes, there be likely impact of change issues.

The Class Diagram • In multi-developer projects, the class diagram represents the ‘best understanding’ of how a program is being developed. • It’s kind of an informal contract with your fellow developers. • One of the benefits we get from object orientation is an easy of development and integration. • But only if everyone is communicating effectively.

Summary • Class diagrams are a useful shorthand notation for classes. • I tell you about them so you’ll know them when you see them. • In addition, they help visualize certain structural problems in object oriented program. • Seeing the problems is the first step in resolving them of course.

2CPP05 - Modelling an Object Oriented Program

More Related Content

What's hot

Viewers also liked

Similar to 2CPP05 - Modelling an Object Oriented Program

More from Michael Heron

Recently uploaded

2CPP05 - Modelling an Object Oriented Program