Object-Orientated Design Unit 3: Objects and Classes

Jin Sa

Session Aims
introduce the concept of objects and classes. present methods for identifying classes given textual descriptions of required system functionality. illustrate the benefits of highly cohesive loosely coupled classes. explain the UML class and object notion. introduce the term encapsulation and show the benefits of applying encapsulation to classes.

What is an Object? -recap

an object knows something its data, and it knows how to do something its functions.
E.g. a Bank account object
may know the balance of the account and provide functions to add or withdraw funds.

In object-orientated programming languages object behaviour is implemented in the form of methods.

Classes and objects

A class is a blueprint for an object. The class defines the generic behaviour of an object and the type of data it may store Objects that behave in a manner specified by a class are called instances of that class.
Example A Film class :
data could include title of the film and the certification rank Methods could be modifying certification rank

One instance of the Film class could contain details of the film The Godfather and another The Dark knight. Each of the instances stores exactly the same type of data, film name, certification and classification yet each one represents a different film.

Classes and objects : summary

Objects are instances of classes. Classes define the behaviour and the data types for an object Data held in instances of the same class will typically vary. Instances of the same class provide exactly the same services (subject to the data not controlling the flow).

Terms, Concepts and UML Notation

In UML, a class is rendered as a rectangle.

UML notation: Class

Every class must have a name, e.g. Student An attribute (data) is a named property of a class that describes a range of values that instances of the property may hold, e.g. every customer has a name and an address. An operation is an implementation of a service that can be requested from

CRC Process
Once you have a reasonable list of candidate classes in your OO design you can further evaluate their place in a particular system by identifying their responsibilities
what they do, and who they need to work with to do this their collaborations. The process is referred to as the Classes Responsibilities and Collaborations process or more commonly as the CRC process.

CRC process

write the names of all candidate classes on a series of cards. work through the textual narrative of the system requirements, i.e. the use case descriptions assigning responsibilities to classes, e.g. determining doing something, knowing something and decision making. Classes that have no responsibilities can be removed because they do not add value to the system

A Common technique modelling the vocabulary of a system

To model the vocabulary of a system, Identify those things users or implementers use to describe the problem or the solution. Use CRC and use case based analysis to help find these abstractions. For each abstraction, identify a set of responsibilities. Make sure that each class is crisply defined and there is a good balance of responsibilities among all your classes. Provide the attributes and the operations that are needed to carry out

Example
Abstractions drawn from a retail problem domain could include: Customer, Order, Product, Shipment, Invoice and Warehouse. Abstract such as Transaction is a solution related abstraction.

Encapsulation
encapsulation refers to the process of an object controlling outside access to its internal data. Client only knows how to call the methods, not how the methods are implemented. Data attributes are made private, i.e. protected from being directly accessed from outside Visible methods (services) are made

Benefits of encapsulation
The main benefit of encapsulation is that the programmer may change the implementation of the object without affecting the whole program, if he or she preserves the interface of the object. Any change of the data representation will affect only the implementation of the methods. By keeping data private and providing public welldefined service methods the role of the object becomes clear to other objects. This increases usability.

Cohesion and Coupling

objects in the system must work together to achieve a common set of goals avoid placing too many responsibilities with a single object. create object that knows how to do one task and they are able to do that task well Example: a system goal such as load the product catalogue, We may have one object that knows how to open and read a file, another object may know how to parse the XML text, a third object may know how to store in memory the data-type structures and so on Alternatively, we could create a single object that did all of these tasks but not flexible for reuse elsewhere as it does too much. Also changing to the code may be difficult because all of the functionality is so tightly linked. Hence we would say the ease of maintenance for this object is poor.

Object coupling and cohesion

Object coupling and cohesion

Cohesive object does one thing only and does that one thing well Low cohesive objects are unclear about their purposes Highly cohesive classes have clearly defined relationships with other classes, and collaborate in clear ways Classes of low cohesion have complex and confused relationships with other classes, and collaborate in complex ways. Within models of tightly coupled classes, a change to one class often has knock-on effects on many other related classes. Strong coupling results in complex models that are difficult to understand and maintain, With loosely coupled classes, a change to one class is often encapsulated to that class, preventing knock-on changes to related classes.

Object coupling and cohesion

In summary, by creating well defined public services you are making it clear what the responsibilities of the object are. By allocating the appropriate responsibilities to a class and not overburdening it you are promoting cohesion and loose coupling. Assigning too many responsibilities to an individual class will promote loose coupling but at the expense of cohesion. Assigning too few responsibilities or misplacing responsibilities will create a system with tight coupling. Therefore as software designers we aim to create highly cohesive objects that are loosely coupling. In reality this will not always be possible and often the skill of the designer is finding the best tradeoffs, a happy medium!

Recap
Classes exist in code and are the blueprints used to create objects Objects are instances of classes and exist at runtime A common modelling technique is to model the vocabulary of the system. Encapsulation is achieved by making data private and services public We seek to develop classes that are highly cohesive and loosely coupled.

Student activity
Complete student activity 3.2