7/16/24, 12:49 PM Object Oriented Analysis and Design: Classes and Objects

More Create Blog Sign In

Classes and Objects

A class is the implementation of an abstract data type (ADT). It defines attributes and methods
which implement the data structure and operations of the ADT, respectively. Instances of
classes are called objects. Consequently, classes define properties and behaviour of sets of
objects.

An object is an instance of a class. It can be uniquely identified by its name and it defines a
state which is represented by the values of its attributes at a particular time.

A program consisting of four objects.

An object is an entity that has state, behavior, and identity. The structure and behavior of
similar objects are defined in their common class. The terms instance and object are
interchangeable. the developer with an object-oriented mindset begins to think that everything
in the world is an object. This perspective is a little naive because some things are distinctly
not objects. For example, attributes such as beauty or color are not objects, nor are emotions
such as love and anger. On the other hand, these things are all potentially properties of other Pages
objects. For example, we might say that a man (an object) loves his wife (another object), or
Home
that a particular cat (yet another object) is gray.
The Object Model
State : Classes and Objects
UML Notation
The state of an object encompasses all of the (usually static) properties of the object plus the
Process
current (usually dynamic) values of each of these properties.The fact that every object has
state implies that every object takes up some amount of space, be it in the physical world or in
computer memory Followers

Example Followers (3)

Consider an abstraction of an employee record. Figure 3–1 depicts this abstraction using the
Unified Modeling Language notation for a class.

Each part of this abstraction denotes a particular property of our abstraction of an employee. Follow
This abstraction is not an object because it does not represent a specific instance. When made
specific, we may have, for example, two distinct objects: Tom and Kaitlyn, each of which takes
up some amount of space in memory (see Figure 3–2). Blog Archive

▼
▼ 2010 (1)
▼
▼ December (1)
Object Oriented Analysis and
Design

https://masters-ooad.blogspot.com/p/classes-and-objects.html 1/9
7/16/24, 12:49 PM Object Oriented Analysis and Design: Classes and Objects

It is good engineering practice to encapsulate the state of an object rather than expose it. For
example, we might change the abstraction (class) as shown in Figure 3–3.

Behavior :

Behavior is how an object acts and reacts, in terms of its state changes and message passing

An operation is some action that one object performs on another in order to elicit a reaction.
For example, a client might invoke the operations append and pop to grow and shrink a queue
object, respectively. A client might also invoke the operation length, which returns a value
denoting the size of the queue object but does not alter the state of the queue itself.

Operations –

five kinds of operations on an object.

- Modifier: an operation that alters the state of an object

- Selector: an operation that accesses the state of an object but does not alter the state

- Iterator: an operation that permits all parts of an object to be accessed in some well-defined
order

- Constructor: an operation that creates an object and/or initializes its state

- Destructor: an operation that frees the state of an object and/or destroys the object itself

Roles and Responsibilities –

Objects play many different roles during their lifetimes . state and behavior of an object
collectively define the roles that an object may play in the world

Identity :

“most programming and database languages use variable names to distinguish temporary
objects, mixing addressability and identity.

Example
Let us assume we instantiate a number of DisplayItem classes as indicated in Figure 3–4a.
Specifically, the manner in which we instantiate these classes sets aside four locations in
memory whose names are item1,item2, item3, and item4, respectively. Here, item1 is the
name of a distinct DisplayItem object, but the other three names each denote a pointer to a
DisplayItem object. Only item2 and item3 actually point to distinct DisplayItem objects
(because in their declarations we allocated a new DisplayItem object); item4 designates no
such object. Furthermore, the names of the objects pointed to by item2 and item3 are
anonymous: We can refer to these distinct objects only indirectly, via their pointer value.

https://masters-ooad.blogspot.com/p/classes-and-objects.html 2/9
7/16/24, 12:49 PM Object Oriented Analysis and Design: Classes and Objects

Although item1 and the object designated by item2 have the same state, they represent
distinct objects. Also, note that we have changed the state of the object designated by item3 by
operating on it through its new indirect name, item4. This is a situation we call structural
sharing, meaning that a given object can be named in more than one way; in other words,
there are aliases to the object. Structural sharing is the source of many problems in object-
oriented programming. Failure to recognize the side effects of operating on an object through
aliases often leads to memory leaks, memory access violations, and, even worse, unexpected
state changes. For example, if we destroyed the object designated by item3, then item4’s
pointer value would be meaningless; this is a situation we call a dangling reference.

Consider also Figure 3–4c, which illustrates the results of modifying the value of the item2
pointer to point to item1. Now item2 designates the same object as item1. Unfortunately, we
have introduced a memory leak: The object originally designated by item2 can no longer be
named, either directly or indirectly, and so its identity is lost. In languages such as Smalltalk
and Java, such objects will be garbage-collected and their storage reclaimed automatically, but
in languages such as C++, their storage will not be reclaimed until the program that created
them finishes. Especially for long-running programs, memory leaks such as this are either
bothersome or disastrous.

Copying, Assignment, and Equality :

<**** will add soon *****>

Relationships among Objects :

Objects contribute to the behavior of a system by collaborating with one another.

Two kinds of object relationships are of particular interest in object-oriented analysis and
design, namely:

1.Links

2.Aggregation

Links -

The term link derives from Rumbaugh et al., who define it as a “physical or conceptual
connection between objects” [16]. An object collaborates with other objects through its links to
these objects. Stated another way, a link denotes the specific association through which one
object (the client) applies the services of another object (the supplier), or through which one
object may navigate to another.

As a participant in a link, an object may play one of three roles.

1.Controller: This object can operate on other objects but is not operated on by other objects.
In some contexts, the terms active object and controller are interchangeable.

2.Server: This object doesn’t operate on other objects; it is only operated on by other objects.

3.Proxy: This object can both operate on other objects and be operated on by other objects. A
proxy is usually created to represent a real-world object in the domain of the application

In the context of Figure 3–5, FlowController acts as a controller object, DisplayPanel acts as a
server object, and Valve acts as a proxy. Example 3–3 illustrates how responsibilities can be
properly separated across a group of collaborating objects.

https://masters-ooad.blogspot.com/p/classes-and-objects.html 3/9
7/16/24, 12:49 PM Object Oriented Analysis and Design: Classes and Objects

Aggregation –

Whereas links denote peer-to-peer or client/supplier relationships, aggregation denotes a

whole/part hierarchy, with the ability to navigate from the whole (also called the aggregate) to
its parts. In this sense, aggregation is a specialized kind of association. For example, as shown
in Figure 3–6, the object Temperature-Controller has a link to the object TemperatureRamp as
well as to Heater. The object TemperatureController is thus the whole, and Heater is one of its
parts

Aggregation may or may not denote physical containment. For example, an airplane is
composed of wings, engines, landing gear, and so on: This is a case of physical containment.
On the other hand, the relationship between a shareholder and his or her shares is an
aggregation relationship that does not require physical containment. The shareholder uniquely
owns shares, but the shares are by no means a physical part of the shareholder. Rather, this
whole/part relationship is more conceptual and therefore less direct than the physical
aggregation of the parts that form an airplane.

The Nature of a Class :

an object is a concrete entity that exists in time and space, a class repre- sents only an
abstraction “A class represents a set of objects that share a common structure and a common
behavior.”A single object is simply an instance of a class.

Interface and Implementation –

The interface of a class provides its outside view and therefore emphasizes the abstraction
while hiding its structure and the secrets of its behavior. This interface primarily consists of the
declarations of all the operations applicable to instances of this class, but it may also include
the declaration of other classes, constants, variables, and exceptions as needed to complete
the abstraction. By contrast, the implementation of a class is its inside view, which
encompasses the secrets of its behavior. The implementation of a class primarily consists of
the implementation of all of the operations defined in the interface of the class.

We can further divide the interface of a class into four parts:

1.Public: a declaration that is accessible to all clients

2.Protected: a declaration that is accessible only to the class itself and its sub- classes

3.Private: a declaration that is accessible only to the class itself

4.Package: a declaration that is accessible only by classes in the same package

Visibility and Friendship –

In particular, C++ allows a developer to make explicit distinctions among all four of these
different parts.

The C++ friendship mechanism permits a class to distinguish certain privileged classes that
are given the rights to see the class’s protected and private parts. Friendships break a class’s
encapsulation and so, as in life, must be chosen carefully. Java does not have friendship.
Instead, Java has a somewhat similar type of visibility called package access, where all
classes in the same package can access each other. Aside from friendship, public, protected,
and private access operate in Java as they do in C++

The state of an object must have some representation in its corresponding class and so is
typically expressed as constant and variable declarations placed in the protected or private
part of a class’s interface. In this manner, the representation common to all instances of a class
https://masters-ooad.blogspot.com/p/classes-and-objects.html 4/9
7/16/24, 12:49 PM Object Oriented Analysis and Design: Classes and Objects
is encapsulated, and changes to this representation do not functionally affect any outside
clients.

Relationships among Classes :

Consider for a moment the similarities and differences among the following classes of objects:
flowers, daisies, red roses, yellow roses, petals, and ladybugs.

We can make the following observations.

- A daisy is a kind of flower.

- A rose is a (different) kind of flower.

- Red roses and yellow roses are both kinds of roses.

- A petal is a part of both kinds of flowers.

- Ladybugs eat certain pests such as aphids, which may be infesting certain kinds of flowers.

In all, there are three basic kinds of class relationships [22]. The first of these is
generalization/specialization, denoting an “is a” relationship. For instance, a rose is a kind of
flower, meaning that a rose is a specialized subclass of the more general class, flower.

The second is whole/part, which denotes a “part of” relation-ship. Thus, a petal is not a kind of
a flower; it is a part of a flower.

The third is association, which denotes some semantic dependency among otherwise unre-
lated classes, such as between ladybugs and flowers. As another example, roses and candles
are largely independent classes, but they both represent things that we might use to decorate
a dinner table

Association –

Of these different kinds of class relationships, associations are the most general but also the
most semantically weak. The identification of associations among classes is often an activity of
analysis and early design,

Example
For a vehicle, two of our key abstractions include the vehicle and wheels. As shown in Figure
3–7, we may show a simple association between these two classes: the class Wheel and the
class Vehicle. (Arguably, an aggregation would be better.) By implication, this association
suggests bidirectional navigation. Given an instance of Wheel, we should be able to locate the
object denoting its Vehicle, and given an instance of Vehicle, we should be able to locate all
the wheels

Here we show a one-to-many association: Each instance of Wheel relates to one Vehicle, and
each instance of Vehicle may have many Wheels

Multiplicity –

Our example introduced a one-to-many association, meaning that for each instance of the
class Vehicle, there are zero (a boat, which is a vehicle, has no wheels) or more instances of
the class Wheel, and for each Wheel, there is exactly one Vehicle. This denotes the multiplicity
of the association. In practice, there are three common kinds of multiplicity across an
association:

1.One-to-one

2.One-to-many

3.Many-to-many

A one-to-one relationship denotes a very narrow association. For example, in retail

telemarketing operations, we would find a one-to-one relationship between the class Sale and
the class CreditCardTransaction: Each sale has exactly one corresponding credit card
transaction, and each such transaction corresponds to one sale. Many-to-many relationships
are also common. For example, each instance of the class Customer might initiate a
transaction with several instances of the class SalesPerson, and each such salesperson might
interact with many different customers

Inheritance -

generalization/specialization relationship (“is a” hierarchy among classes)

“A subclass may inherit the structure and behavior of its superclass.”

https://masters-ooad.blogspot.com/p/classes-and-objects.html 5/9
7/16/24, 12:49 PM Object Oriented Analysis and Design: Classes and Objects

As for the class ElectricalData, this class inherits the structure and behavior of the class
TelemetryData but adds to its structure (the additional voltage data), redefines its behavior (the
function transmit) to transmit the additional data, and can even add to its behavior (the function
currentPower, a function to provide the current power level).

Single Inheritance:

inheritance is a relationship among classes wherein one class shares the structure and/or
behavior defined in one (single inheritance) or more (multiple inheritance) other classes class
from which another class inherits its superclass. class that inherits from one or more classes
a subclass

Figure 3–9 illustrates the single inheritance relationships deriving from the superclass
TelemetryData. Each directed line denotes an “is a” relationship. For example, CameraData “is
a” kind of SensorData, which in turn “is a” kind of TelemetryData

Classes with no instances are called abstract classes. An abstract class is written with the
expectation that its subclasses will add to its structure and behavior, usually by completing the
implementation of its (typically) incomplete methods.

Polymorphism –

polymorphism, by which symbols such as + could be defined to mean different things. We call
this concept overloading. In C++, one may declare functions having the same names, as long
as their invocations can be distinguished by their signatures, consisting of the number and
types of their arguments

Early Binding (static) vs Late binding (Dynamic) :

Polymorphism and late binding go hand in hand. In the presence of polymorphism, the binding
of a method to a name is not determined until execution. In C++, the developer may control
whether a member function uses early or late binding. Specifically, if the method is declared as
virtual, then late binding is employed, and the function is considered to be polymorphic. If this
virtual declaration is omitted, then the method uses early binding and thus can be resolved at
the time of compilation. Java simply performs late binding without the need for an explicit
declaration such as virtual. How an implementation selects a particular method for execution is
described in the sidebar, Invoking a Method.

Invoking a Method

Consider the class hierarchy in Figure 3–10, which shows the base class DisplayItem along
with three subclasses named Circle, Triangle, and Rectangle. Rectangle also has one
subclass, named SolidRectangle.

In the class DisplayItem, suppose that we define the instance variable theCenter (denoting the
coordinates for the center of the displayed item), along with the following operations as in our
earlier example:

■ draw Draw the item.

https://masters-ooad.blogspot.com/p/classes-and-objects.html 6/9
7/16/24, 12:49 PM Object Oriented Analysis and Design: Classes and Objects
■ move Move the item.

■ location Return the location of the item.

The operation location is common to all subclasses and therefore need not be redefined, but
we expect the operations draw and move to be redefined since only the subclasses know how
to draw and move themselves

The class Circle must include the instance variable theRadius and appropriate operations to
set and retrieve its value. For this subclass, the redefined operation draw draws a circle of the
given radius, centered on theCenter. Similarly, the class Rectangle must include the instance
variables theHeight and theWidth, along with appropriate operations to set and retrieve their
values. For this subclass, the operation draw draws a rectangle with the given height and
width, again centered on theCenter. The subclass SolidRectangle inherits all characteristics of
the class Rectangle but again redefines the behavior of the operation draw. Specifically, the
implementation of draw for the class SolidRectangle first calls draw as defined in its superclass
Rectangle (to draw the outline of the rectangle) and then fills in the shape. The invocation of
draw demands polymorphic behavior.

Suppose now that we have some client object that wishes to draw all of the subclasses. In this
situation, the compiler cannot statically generate code to invoke the proper draw operation
because the class of the object being operated on is not known until runtime.

More strongly typed languages such as C++ do let the developer assert such information.
Because we want to avoid method dispatch wherever possible but must still allow for the
occurrence of polymorphic dispatch, invoking a method in these languages proceeds a little
differently than in Smalltalk.

In C++, the developer can decide whether a particular operation is to be bound late by
declaring it to be virtual; all other methods are considered to be bound early, and thus the
compiler can statically resolve the method call to a simple subprogram call. To handle virtual
member functions, most C++ implementations use the concept of a vtable, which is defined for
each object requiring polymorphic dispatch, when the object is created (and thus when the
class of the object is fixed). This table typically consists of a list of pointers to virtual functions.

For example, if we create an object of the class Rectangle, then the vtable will have an entry
for the virtual function draw, pointing to the closest implementation of draw. If, for example, the
class DisplayItem included the virtual function Rotate, which was not redefined in the class
Rectangle, then the vtable entry for Rotate would point to the implementation of Rotate in the
class DisplayItem. In this manner, runtime searching is eliminated: Referring to a virtual
member function of an object is just an indirect reference through the appropriate pointer,
which immediately invokes the correct code without searching

Multiple Inheritance:

With single inheritance, each subclass has exactly one superclass. Consider for a moment
how one might organize various assets such as savings accounts, real estate, stocks, and
bonds. Savings accounts and checking accounts are both kinds of assets typically managed
by a bank, so we might classify both of them as kinds of bank accounts, which in turn are kinds
of assets. Stocks and bonds are managed quite differently than bank accounts, so we might
classify stocks, bonds, mutual funds, and the like as kinds of securities, which in turn are also
kinds of assets.

Unfortunately, single inheritance is not expressive enough to capture this lattice of

relationships, so we must turn to multiple inheritance. Figure 3–11 illustrates such a class
structure. Here we see that the class Security is a kind of Asset as well as a kind of
InterestBearingItem. Similarly, the class BankAccount is a kind of Asset, as well as a kind of
InsurableItem and InterestBearingItem.

Designing a suitable class structure involving inheritance, and especially involving multiple
inheritance, is a difficult task. This is often an incremental and iterative process. Two problems
present themselves when we have multiple inheritance: How do we deal with name collisions
from different superclasses, and how do we handle repeated inheritance?

Name collisions are possible when two or more different superclasses use the same name for
some element of their interfaces, such as instance variables and methods. For example,
suppose that the classes InsurableItem and Asset both have attributes named presentValue,
denoting the present value of the item. Since the class RealEstate inherits from both of these
classes, what does it mean to inherit two operations with the same name? This in fact is the

https://masters-ooad.blogspot.com/p/classes-and-objects.html 7/9
7/16/24, 12:49 PM Object Oriented Analysis and Design: Classes and Objects
key difficulty with multiple inheritance: Clashes may introduce ambiguity in the behavior of the
multiply inherited subclass.

There are three basic approaches to resolving this kind of clash. First, the language semantics
might regard such a clash as illegal and reject the compilation of the class. Second, the
language semantics might regard the same name introduced by different classes as referring
to the same attribute. Third, the language semant ics might permit the clash but require that all
references to the name fully qualify the source of its declaration.

The second problem is repeated inheritance, which Meyer describes as follows:

“One of the delicate problems raised by the presence of multiple inheritance is what happens
when a class is an ancestor of another in more than one way. If you allow multiple inheritance
into a language, then sooner or later someone is going to write a class D with two parents B
and C, each of which has a class A as a parent—or some other situation in which D inherits
twice (or more) from A. This situation is called repeated inheritance and must be dealt with
properly” [41]. As an example, suppose that we define the (ill-conceived) MutualFund class as
a subclass of the classes Stock and Bond. This class introduces repeated inheritance of the
class Security, which is a superclass of both Stock and Bond (see Figure 3–11).

There are various approaches to dealing with the problem of repeated inheritance.

First, we can treat occurrences of repeated inheritance as illegal. Second, we can permit
duplication of superclasses but require the use of fully qualified names to refer to members of
a specific copy. Third, we can treat multiple references to the same class as denoting the same
class. Different languages handle this approach differently.

Aggregation –

Whole/part relationship (has-a relationship)

As we show in Figure 3–12, the class TemperatureController denotes the whole, and the class
Heater is one of its parts. In the case of the class TemperatureController, we have aggregation
as containment by value, a kind of physical containment meaning that the Heater object does
not exist independently of its enclosing Temperature Controller instance. Rather, the lifetimes
of these two objects are intimately connected:

When we create an instance of Temperature Controller, we also create an instance of the class
Heater. When we destroy our TemperatureController object, by implication we also destroy the
corresponding Heater object.

Composition –

A less direct kind of aggregation is also possible, called composition, which is containment by
reference. In this case, the class Temperature Controller still denotes the whole, and an
instance of the class Heater is still one of its parts, although that part must now be accessed

https://masters-ooad.blogspot.com/p/classes-and-objects.html 8/9
7/16/24, 12:49 PM Object Oriented Analysis and Design: Classes and Objects
indirectly. Hence, the lifetimes of these two objects are not so tightly coupled as before: We
may create and destroy instances of each class independently.

On Building Quality Classes and Objects :

In our experience, the design of classes and objects is an incremental, iterative process.
Frankly, except for the most trivial abstractions, we have never been able to define a class
exactly right the first time. It takes time to smooth the conceptual jagged edges of our initial
abstractions

Measuring the Quality of an Abstraction –

How can one know if a given class or object is well designed? We suggest five meaningful
metrics:

1.Coupling

2.Cohesion

3.Sufficiency

4.Completeness

5.Primitiveness

define coupling as “the measure of the strength of association established by a connection

from one module to another. Strong coupling complicates a system since a module is harder
to understand, change, or correct by itself if it is highly interrelated with other modules.
Complexity can be reduced by designing systems with the weakest possible coupling between
modules”

Coupling with regard to modules still applies to object-oriented analysis and design, but
coupling with regard to classes and objects is equally important. How-ever, there is tension
between the concepts of coupling and inheritance because inheritance introduces significant
coupling. On the one hand, weakly coupled classes are desirable; on the other hand,
inheritance—which tightly couples superclasses and their subclasses—helps us to exploit the
commonality among abstractions.

Home

Subscribe to: Posts (Atom)

Simple theme. Powered by Blogger.

https://masters-ooad.blogspot.com/p/classes-and-objects.html 9/9