

























Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
This lecture is part of lecture series for Software Engineering course. Prof. Prateek Aron delivered this lecture at Allahabad University. Its main points are: Object-orientation, Data, Structure, Functionality, Communicate, Interface, Inheritance, Polymorphism, Dynamic, Binding
Typology: Slides
1 / 33
This page cannot be seen from the preview
Don't miss anything!


























We continue to explore the question “what are good systems like?” by describing the object oriented paradigm.
We shall answer these questions:
What is an object? How do objects communicate? How is an object’s interface defined? What have objects to do with components?
Finally we consider inheritance, polymorphism and dynamic binding.
Conceptually, an object is a thing you can interact with: you can send it various messages and it will react
How it behaves depends on the current internal state of the object, which may change For example: as part of the object’s reaction to receiving a message.
It matters which object you interact with, an object has an identity which distinguishes it from all other objects.
behaviour, state and identity [Grady, Booch, 1991]
Shared data areas are eliminated. Objects communicate by message passing. Objects are independent and encapsulate state and representation information. Their independence can lead to easier maintenance
The way an object acts and reacts, in terms of its state changes as message passing.
An object understands certain messages,
it can receive the message and act on them.
The set of messages that the object understands, like the set of attributes it has, is normally fixed.
The idea is that objects are not defined just by the current values of their attributes
An object has a continuous existence
For example the values of the object’s attributes could change, perhaps in response to a message, but it would still be the same object.
A message includes a selector ; here we’ve seen the selectors reportTime and resetTimeTo
A message may, but need not, include one or more arguments
Often, for a given selector there is a single “correct” number of arguments (Recall method overloading however..)
The object’s public interface defines which messages it will accept
An object can also send to itself any message which it is capable of understanding (in either its public or private interface )
So typically an object has two interfaces:
The public interface (any part of the system can use) The larger private interface (which the object itself and other privileged parts of the system can use)
objects with the same data structure (attributes) and behaviour (operations) are grouped into a class
each class defines a possibly infinite set of objects
docsity.com
Each object is an instance of a class
Each object knows its class
Each instance has its own value for each attribute (state) but shares the attribute names and operations with other instances of the class also “static” i.e. class variables
A class encapsulates data and behaviour, hiding the implementation details of an object
Why not just have objects, which have state, behaviour and identity as we require?
Classes in object oriented languages serve two purposes:
Convenient way of describing a collection (a class) of objects which have the same properties In most modern OO languages, classes are used in the same way that types are used in many other languages To specify what values are acceptable
Often, people think of classes and types as being the same thing (indeed it is sometimes convenient and not misleading to do so). It is not strictly correct however.
Remember that a class does not only define what messages an object understands!
It also defines what the object does in response to the messages.
Inheritance is the sharing of attributes and operations among classes based upon a hierarchical relationship
A class can be defined broadly and then refined into successively finer subclasses
Each subclass incorporates or inherits all of the properties of its super class and its own unique properties