Fundamentals of Object

OrientedTechnology
- Classes and Objects

1. Objects
2. Classes
3. Visibility
4. Polymorphism
 Objects

• Object is a tangible entity which exhibits some well-

defined behavior.
• Object has crisply defined boundaries.
• Object models some part of reality and is something
that exists in time and space.
• An object has state, behavior , and identity.
• The structure and behavior of similar objects are
defined in their common class.
• Instance and object are interchangeable terms.
 Objects
• What is an Object?
• Informally, an object represents an entity,
either physical, conceptual, or software
• Physical entity

• Conceptual entity

• Software entity
 Objects
• What is an Object?
• Informally, an object
represents an entity,
either physical,
conceptual, or software
• Physical entity

• Conceptual entity Chemical Process

• Software entity
 A More Formal Definition
• An object has a state,behaviour and
identity,the structure and behaviour of
similar objects are defined in their common
class;
• An object is something that has
• State
• Behavior
• Identity
 Object
• State: encompasses all of the properties of
the object (usually static)+ the current
values of each of these properties (usually
dynamic)
• Behavior: how an object acts and reacts, in
terms of its state changes and message
passing.
• Identity: property of an object which
distinguishes it from all other objects.
 State
• The state of an object encompasses all of
the properties of the object plus the current
values of each of these properties.
• Examples includes the following.
Vending machine
 State
• The state of an object is one of the possible
conditions in which an object may exist
• The state of an object normally changes
over time
 State
• low-level definition:
• The state of an object encompasses all of
the (usually static) properties of the object
plus the current (usually dynamic) values
of each of these properties.
 OBJECTS
• Consider the structure of a personnel record. In C+
+ we might write:
struct PersonnelRecord
{
char name[100];
int socialSecurity_Number;
char department[10];
float salary;
}
 Behavior
• No object exists in isolation .
• Objects are acted upon and themselves act
upon other objects.
• Behavior is how an object acts and reacts, in
terms of its state changes and message
passing.
• The state of an object represents the
cumulative results of its behavior.
 Behavior
• An Object Has Behavior
• Behavior determines how an
object acts and reacts to
requests from other objects
• Behavior is represented by the
set of messages it can respond
to (the operations the object
can perform)

Assign Y.Welikala

(Returns: conformation)

Registration System Oops course

 Operations
• An operation denotes a service that a class
offers to its clients.A client offers 5 kinds of
operations upon an object
• 1)Modifier:An operation that alters the state of an object
• 2)Selector:An operation that accesses the state of an object,but
doesnot alter the state
• 3)Iterator:An operation thet permits all parts of an object to be
accessed in some well defined order.
• 4)Constructor:An operation that creates an object and
or/initializes its state.
• 5)Destructor:An operation that frees the state of an object
and/or destroys the object itself.
 Identity
• Identity is a property of an object which
distinguishes if from other objects.
• It could be a name ,number etc.
 An Object Has Identity
• Each object has a
unique identity, even
if its state is identical
to that of another
object
 Relationships among objects
• Kinds of relationships:
• In OOAD 2 kinds of object hierarchies are
there:
• 1)Link
• 2)Aggregation
• Seidewitz and stark call these seniority and
parent/child relationships
 link
• A physical or conceptual connection between objects
• An object collaborates with other objects through its links
to these objects.
• A link denotes the specific association through which one
object(the client) applies the services of another
object(the supplier).
• Message passing between objects may be
unidirectional,but sometimes bidirectional.
• Mainly denote client/server relationships.
• As a participiant in a link,an object may play one of these
roles
• Actor:An object that can operate upon other objects but
is never operated by other objects.In some contexts active
object and actor are interchangable.
• Server:An object that never operates upon other
objects,it is only operated upon by other objects.
• Agent:An object that can both operate upon other objects
and be operated upon by other objects.
 visibility
• We must consider visibility across links
• 4 different ways that one object may have visibility
to another
• 1)The supplier object is global to the client
• 2)The supplier object is a parameter to some
operation of the client
• 3)The supplier object is a part of the client object
• 4)The supplier object is a locally declared object in
some operation of the client
 synchronization
• Whenever one object passes a message to
another across a link,the 2 objects are said to be
synchronized.
• If an active object has a link to a passive
object,we must choose one of three approaches
• Sequential
• Guarded
• Synchronous
• 1)Sequential:The semantics of the passsive object
are guaranteed only in the presence of a single active
object at a time.
• 2)Guarded:The semantics of the passive object are
guaranteed in the presence of multiple threads of
control,but the active clients must collaborate to
achieve mutual exclusion.
• 3)Synchronous:The semantics of the passive object
are guaranteed in the presence of multiple threads of
control,and the supplier guarantees mutual exclusion
 Aggregation

• Semantics:Aggregation denotes a whole/part

hierarchy,with the ability to navigate from the
whole(also called the aggregate) to its parts(attributes)
• whole/part relationship is more conceptual.
• Eg:relationship between a shareholder and her shares is
an aggregation relationship that doesnot require physical
containment;The shareholder uniquely hold shares ,but
the shares are by no means a physical part of the
shareholder.
• Airplane composed of wings.
 Aggregation Vs Links
• Aggregation is some times better because it encapsulates
parts as secrets of the whole.
• Links are sometimes better because they permit looser
coupling among objects.
• Intelligent engineering decisions require careful weighing
of these two factors.
Classes
 Class
• A class is a description of a group of objects
with common properties (attributes),
behavior (operations), relationships, and
semantics
• An object is an instance of a class
• A class is an abstraction in that it:
• Emphasizes relevant characteristics
• Suppresses other characteristics
 Interface and implementation

• Outside view and inside view of a class

• The interface of a class provides its outside
view and therefore emphasizes the
abstraction while hiding its structure and
the secrets of its behavior.
• The implementation of a class is its inside
view,which encompasses the secrets of its
behavior.
• The interface of the class can be divided into 3 parts.
• Public:A declaration that is accessible to all clients.
• Protected:A declaration that is accessible only to the
class itself,its subclasses,and its friends
• Private:A declaration that is accessible only to the
class itself and its friends.
 Class
• Often appear as nouns in problem descriptions

• Each class may have zero, one or more objects

• Each object knows its class

• Class relationship might indicate some sort
of sharing.Eg:Daisy and roses share
common properties.
• Class relationship might indicate some
kind of semantic connection.Eg:red rose
and yellow rose are more alike.
 Relationship among classes
• Kinds of relationships:
• Most object oriented languages provide direct support for
some combination of the following relationships:
• Association
• Inheritance
• Aggregation
• Using
• Instantiation
• Metaclass
Association
• An association denotes a semantic
dependency
• The class product denotes products
sold as part of a sale,the class sale
denotes the transaction through which
several products were last sold.
•   Association is a relationship where
all object have their own lifecycle and
there is no owner. Let’s take an
example of Teacher and Student.
Multiple students can associate with
single teacher and single student can
associate with multiple teachers but
there is no ownership between the
objects and both have their own
lifecycle. Both can create and delete
independently.
•  
 Associations & Links...

• Associations are bi-directional

– may be implemented as unidirectional
• Associations may be
– one-to-one
– one-to-many
– many-to-one
– many-to-many
 Associations

Category Relationship
Linear one one
Hierarchical one many
Graph many  many
Sets none  none
 Associations
One-to-one relationship between elements
• Each element has unique predecessor
• Each element has unique successor
 Examples of association
• List
Collection of elements in order
• Queue
Elements removed in order of insertion
First-in, First-out (FIFO)
 Associations
• One-to-many relationship between elements
Each element has unique predecessor
Each element has multiple successors
 Example One to many

• Tree
Single root
 Association- example
• Many-to-many relationship between elements
Each element has multiple predecessors
Each element has multiple successors
 Inheritance
• Single inheritance(“is a”):
• Classes with no instances are called
abstract classes.
• A class has 2 kinds of clients
• Instances
• Subclasses.
• Multiple inheritance
• Polymorphism
• Superclass-subclass-
 Aggregation
Aggregation:
• Part-of relationship
• In this objects representing the components of something are
associated with an object representing the entire assembly.
• .
•  Aggregation is a specialize form of Association where all object
have their own lifecycle but there is ownership ,and child object can
not belongs to another parent object. Let’s take an example of
Department and teacher. A single teacher can not belongs to multiple
departments, but if we delete the department teacher object will not
destroy. We can think about “has-a” relationship.
 Using
• Using relationship is one possible refinement of an
association, where by we assert which abstraction is the
client and which is the supplier of certain services.
• Strict “using "relationships are occasionally too confining
because they allow the client access only to the public
interface of the supplier.
• One class may use another in a variety of ways., Here
Temperature controller will use temperature ramp in the
signature of its interface
 metaclass
• A class of the class is known as metaclass.
• A metaclass is a class whose instances are
themselves classes.
• In languages such as smalltalk,the primary
purpose of a metaclass is to provide class
variables.,which are shared by all instances of the
class and operations for initializing class
variables
• C++ doesnot explicitly support metaclasses,its
constructor and destructor semantics serve the
purpose of metaclass creation operations.
3.5 The Interplay of Classes and
Objects
Relationships between classes and objects

• Every object is some instance of some

class,and every class has zero or more
instances.
• For practically all applications classes are
static;therefore their existence,semantics
and relationships are fixed prior to the
execution of a program.
 The role of Classes and Objects in
Analysis and Design
• During analysis and early stages of design ,the
developer has two primary tasks:
• 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 behaviors that
satisfy the requirements of the problem.
• Such classes and objects ,collectively are
keyabstractions of the problem.
• These cooperative structures are the
mechanisms of the implementation.
 On building the Quality Classes and
Objects
• Measuring the Quality of an Abstraction
• Inorder to understand whether a given class or
object is well designed,5 meaningfull metrices
are there:
• 1)Coupling
• 2)Cohesion
• 3)Sufficiency
• 4)Completeness
• 5)Primitiveness
• Coupling:
• The measure of the strength of association
established by a connection from one
module to another.
• 2 types:
• 1)Strong Coupling
• 2)Weak Coupling
• Strong Coupling:This complicates a
system since a module is harder to
understand,change or correct by itself,if it
is highly interrelated with other modules.
• Weak Coupling:Complexity can be
reduced by designing systems with
weakest possible coupling between the
objects.
 Cohesion
• Cohesion measures the degree of
connectivity among the elements of a single
module ( a single class or object).
• coincidental cohesion
• functional cohesion
• The least desirable form of cohesion is
coincidental cohesion,in which entirely
unrelated abstractions are thrown into the
same class or module. Example – A class
comprising the abstractions of cat and motor
vehicle. Their behaviors are quite unrelated.
• The most desirable form of cohesion is
functional cohesion, in which the elements
of a class or module all work together to
provide some well-bounded behavior.
 Sufficient
• A class or module should be sufficient, complete,
and primitive.
• By sufficient, we mean that the class or module
captures enough characteristics of the abstraction to
permit meaningful and efficient interaction.
• For example, if we are designing the class Set, it is
wise to include an operation that removes an item
from the set, but our wisdom is futile if we neglect
an operation that adds an item. In practice,
violations of this characteristic are detected very
early; such shortcomings rise up almost every time
we build a
• client that must use this abstraction.
 Complete
• By complete, we mean that the interface of
the class or module captures all of the
meaningful characteristics of the abstraction.
• A complete class or module is thus one
whose interface is general enough to be
commonly usable to any client.
• Primitive operations are those that can be
efficiently implemented only if given access
to the underlying representation of the
abstraction.
 Primitiveness
• Primitiveness :-Many high level
operations are composed from low-level
ones. Hence classes and modules can be
primitive.
• Primitive operations are those that can be
efficiently implemented only if given
access to the underlying representation of
the abstraction.
 Choosing operations
• Functional Semantics:
• The various criteria to be fulfilled for defining
the methods of the classes includes the following
• They should be reusable.
• What is the complexity involved?- How difficult
is it to implement the behavior.
• Applicability- How relevant is the behavior to
the type in which it might be placed.
 Functional Semantics.

• Implementation Knowledge- Does the

behavior’s implementation depend upon
the internal details of the type.
 Time and space semantics
• Time required to complete an operation
and the amount of storage it needs, are to
be specified.
• The decisions are often expressed in terms
of best, average, and worst cases. The
worst case specifies an upper limit on what
it is acceptable.
 Time and space semantics
• If threads are used to minimize time then
they should be properly synchronized.
• Message passing is to be done to achieve
synchronization.
• Different operations may require different
kinds of synchronization.
• Message passing may thus take one of the
following forms:
Synchronous
• Balking
• Timeout
• Asynchronous
 Time and space semantics
• Synchronous- An operation commences
only when the sender has initiated the
action and the receivers is ready to accept
the message.
• The sender and the receiver will wait
indefinitely until both parties are ready to
proceed.
 Time and space semantics
• Balking :- Same as synchronous ,except that the
sender will abandon the operation if the receiver
is not immediately ready.
• Time Out- Same as synchronous ,except that the
sender will only wait for a specified amount of
time for the receiver to be ready.
• Asynchronous: A sender may initiate an action
regardless of whether he receiver is expecting the
message.
 Choosing Relationships
• Collaborations:- Choosing the
relationships among classes and among
object is linked to the selection of
operations.
• In case Object X sends message M to
object Y then directly or indirectly Y
must be accessible to x;
 Choosing Relationships
• One useful guideline in choosing the
relationships among objects is called the
Law of Demeter.
 Law of Demeter
“Methods of a class should not depend in any
way on the structure of any class, except
the immediate structure of their own class.
Further, each method should send messages
to objects belonging to a very limited set of
classes only.”
• Each method should send messages to
object belonging to a very limited set of
classes only.
 Mechanisms and visibility
• During design process ,it is occasionally
useful to state explicitly how one object is
visible to another.
• Deciding upon the relationships among
objects is mainly a matter of designing the
mechanisms whereby these objects
interact.
 Choosing Implementations
• Implementation involves two different
decisions
• A choice of representation for a class or
object and the placement of the class or
object in a module.
• Representation and packaging are the two
main activities involved in implementation
 Representation
• Representation of a class or object should
always be one of the encapsulated secrets
of the abstraction.
• This makes it possible to change the
representation without violating any of the
functional assumptions that clients may
have made.