1

ABSTRACT
SHEELU
A type of programming in which programmers define not only the data type of a data structure, but also the
types of operations (functions) that can be applied to the data structure. n this way, the data structure
becomes an object that includes both data and functions. n addition, programmers can creat e
relationships between one obj ect and another. For example, objects can inherit characteristics from other
objects.
One of the principal advantages of object-oriented programming techniques over procedural programming
techniques is that they enable programmers to create modules that do not need to be changed when a
new type of object is added. A programmer can simply create a new obj ect that inherits many of its
features from existing objects. This makes object-oriented programs easier to modify.
To perform obj ect-oriented programming, one needs an object-oriented programming language (OOPL).
Java, C++ and Smalltalk are three of the more popular languages, and there are also object-oriented
versions of Pascal.













1. Definition of OOP:
Object-oriented programming (OOP) is a programming paradigm using "objects" data
structures consisting oI data Iields and methods together with their interactions to design
applications and computer programs. Programming techniques may include Ieatures such as
data abstraction, encapsulation, messaging, modularity, polymorphism, and inheritance.
OOP uses objects as its Iundamental building blocks. Each object is an instance oI some class.
Classes allow the mechanism oI data abstraction Ior creating new data types. Inheritance allows
building oI new classes Irom existing classes. Hence iI any oI these elements are missing in a
program we cannot consider that program as objected oriented program.
Object-oriented programming is a programming methodology that associates data structures
with a set oI operators which act upon it. In OOP`s terminology an instance oI such an entity is
known as an object. It gives importance to relationships between objects rather than
implementation details. Hiding the implementation details within an object results in the user
being more concerned with an objects relationship to the rest oI the system, than the
implementation oI the object`s behavior.
The concepts and rules used in object-oriented programming provide these important beneIits:
O The concept oI a data class makes it possible to deIine subclasses oI data objects that
share some or all oI the main class characteristics. Called inheritance, this property oI
OOP Iorces a more thorough data analysis, reduces development time, and ensures
more accurate coding.
O $ince a class deIines only the data it needs to be concerned with, when an instance oI
that class (an object) is run, the code will not be able to accidentally access other
program data. This characteristic oI data hiding provides greater system security and
avoids unintended data corruption.
O The deIinition oI a class is reuseable not only by the program Ior which it is initially
created but also by other object-oriented programs (and, Ior this reason, can be more
easily distributed Ior use in networks).
O The concept oI data classes allows a programmer to create any new data type that is not
already deIined in the language itselI.



1.1 Objects:
Object is the basic unit oI object-oriented programming. Objects are identiIied by its unique
name. An object represents a particular instance oI a class. There can be more than one instance
oI a class. Each instance oI a class can hold its own relevant data.
Cb[ecL ls a collecLlo of daLa members ad assoclaLed member fucLlos also kow as
meLhods
Objects are key to understanding obfect-oriented technology. We can Iind many examples oI
real-world objects: our dog, our desk, our television set, and our bicycle. Real-world objects
share two characteristics: They all have state and behavior. Dogs have state (name, color, breed,
hungry) and behavior (barking, Ietching, wagging tail). Bicycles also have state (current gear,
current pedal cadence, current speed) and behavior (changing gear, changing pedal cadence,
applying brakes). IdentiIying the state and behavior Ior real-world objects is a great way to
begin thinking in terms oI object-oriented programming.
Observe the real-world objects that are in your immediate area. "What possible states can this
object be in?" and "What possible behavior can this object perIorm?". As you do, you'll notice
that real-world objects vary in complexity; your desktop lamp may have only two possible
states (on and oII) and two possible behaviors (turn on, turn oII), but your desktop radio might
have additional states (on, oII, current volume, current station) and behavior (turn on, turn oII,
increase volume, decrease volume, seek, scan, and tune). You may also notice that some
objects, in turn, will also contain other objects. These real-world observations all translate into
the world oI object-oriented programming.

A soItware object.


$oItware objects are conceptually similar to real-world objects: they too consist oI state and
related behavior. An object stores its state in 1ields (variables in some programming languages)
and exposes its behavior through methods (Iunctions in some programming languages).
Methods operate on an object's internal state and serve as the primary mechanism Ior object-to-
object communication. Hiding internal state and requiring all interaction to be perIormed
through an object's methods is known as data encapsulation a Iundamental principle oI object-
oriented programming.
Consider a bicycle, Ior example:


A bicycle modeled as a soItware object.
By attributing state (current speed, current pedal cadence, and current gear) and providing
methods Ior changing that state, the object remains in control oI how the outside world is
allowed to use it. For example, iI the bicycle only has 6 gears, a method to change gears could
reject any value that is less than 1 or greater than 6. Bundling code into individual soItware
objects provides a number oI beneIits, including:
1. Modularity: The source code Ior an object can be written and maintained independently
oI the source code Ior other objects. Once created, an object can be easily passed around
inside the system.
2. InIormation-hiding: By interacting only with an object's methods, the details oI its
internal implementation remain hidden Irom the outside world.
3. Code re-use: II an object already exists (perhaps written by another soItware developer),
you can use that object in your program. This allows specialists to implement/test/debug
complex, task-speciIic objects, which you can then trust to run in your own code.
4. Pluggability and debugging ease: II a particular object turns out to be problematic, you
can simply remove it Irom your application and plug in a diIIerent object as its


replacement. This is analogous to Iixing mechanical problems in the real world. II a bolt
breaks, you replace it, not the entire machine.
1.2 Classes:
Classes are data types based on which objects are created. Objects with similar properties and
methods are grouped together to Iorm a Class. Thus a Class represents a set oI individual
objects. Characteristics oI an object are represented in a class as Properties. The actions that can
be perIormed by objects become Iunctions oI the class and are reIerred to as Methods. For
example consider we have a Class oI Cars under which $antro Xing, Alto and WaganR
represents individual Objects. In this context each Car Object will have its own, Model, Year oI
ManuIacture, Color, Top $peed, Engine Power etc., which Iorm Properties oI the Car class and
the associated actions i.e., object Iunctions like $tart, Move, and $top Iorm the Methods oI Car
Class.
No memory is allocated when a class is created. Memory is allocated only when an object is
created, i.e., when an instance oI a class is created.The Iollowing Bicycle class is one possible
implementation oI a bicycle:
class Bicycle
int cadence 0;
int speed 0;
int gear 1;
void changeCadence(int newValue)
cadence newValue;
}
void changeGear(int newValue)
gear newValue;
}
void speedUp(int increment)
speed speed increment;
}
void applyBrakes(int decrement)
speed speed - decrement;
}
void print$tates()


$ystem.out.println("cadence:"cadence" speed:"speed" gear:"gear);
}
}
The syntax oI the Java programming language will look new to you, but the design oI this class
is based on the previous discussion oI bicycle objects. The Iields cadence, speed, and gear
represent the object's state, and the methods (changeCadence, change Gear, speedup etc.) deIine
its interaction with the outside world.
1.3 Inheritance:
Inheritance is the process oI Iorming a new class Irom an existing class or base class. The base
class is also known as parent class or super class. The new class that is Iormed is called derived
class. Derived class is also known as a child class or sub class. Inheritance helps in reducing the
overall code size oI the program, which is an important concept in object-oriented
programming. For example, sedans, sports cars, and roadsters are all types oI cars. In the object
oriented language, sports cars, sedans, and roadsters are subclasses oI the class cars.
The class cars is a "superclass" oI sedans, roadsters, and sports cars. Every subclass will inherit
a state Irom the superclass. The various types oI cars such as sedans and roadsters will share
certain behaviors such as braking. Despite this, subclasses are not restricted to the behaviors and
states that they have taken Irom their superclass. A subclass can combine methods and variables
with the traits they have inherited Irom their superclass. For example, while a sedan may have
Iour dours, sports cars will generally have two. It is also possible Ior subclasses to override any
methods that they have inherited, and they can create unique implementations Ior these
methods.

As an example oI this, you can "override" certain traits within a car to allow it to do diIIerent
things. It is also possible to use more than just one level oI inheritance. An inheritance structure
can be generated which can be as deep as you want it to be. This inheritance structure is called a
class hierarchy. The variables and methods can extend through the levels oI the class hierarchy.
In most cases, a hierarchy that is deep tends to have behaviors which are distinct. However,
there are a number oI important things you should know about a class hierarchy. It should
always deIine what the classes are instead oI how they are used.


For example, iI you are implementing a class Ior muscle cars, it may be helpIul to set it up as a
subclass oI the class cars. The reason Ior this is because muscle cars are a subgroup oI the class
cars that have large amounts oI power. At the same time, because a muscle car is a subgroup oI
the class cars, you would not want to connect them together directly. II you do this, you may
conIuse those that use your program. They may become conIused because the muscle car could
have methods that are not necessary, and this could make it diIIicult to handle the application.
The object class should be at the zenith oI the class hierarchy. Every class should descend Irom
it in a direct or indirect manner. The variable oI an object type can retain a reIerence Ior any
object, and an example oI this would be a class. For example, the object could deIine behaviors
that may be attributed to the objects that are processed by the Java Virtual Machine. There are a
number oI power advantages to the concept oI inheritance. $ubclasses can generate distinct
behaviors which are based on the common attributes that are present in their superclass.
Because oI inheritance, it is possible Ior programmers to use the same code many times over.
In addition to this, programmers can generate superclasses which are named abstract classes.
Abstract classes will characterise behaviors which are common. While some aspects oI this
behavior may be deIined, a large portion oI it will not be deIined at all.
This will allow other developers to Iill in the blank spaces with unique subclasses. As you can
see, an inheritance is extremely important. It shows how subclasses are connect to their
superclasses, and it can also allow you to understand which traits have been passed Irom the
superclass to its subclasses. It is one oI the most powerIul Ieatures oI object oriented
programming. It is used in a number oI popular programming languages such as Java
DiIIerent kinds oI objects oIten have a certain amount in common with each other. Mountain
bikes, road bikes, and tandem bikes, Ior example, all share the characteristics oI bicycles
(current speed, current pedal cadence, current gear). Yet each also deIines additional Ieatures
that make them diIIerent: tandem bicycles have two seats and two sets oI handlebars; road bikes
have drop handlebars; some mountain bikes have an additional chain ring, giving them a lower
gear ratio.
Object-oriented programming allows classes to inherit commonly used state and behavior Irom
other classes. In this example, Bicycle now becomes the superclass oI MountainBike,
RoadBike, and TandemBike. In the Java programming language, each class is allowed to have
one direct superclass, and each superclass has the potential Ior an unlimited number oI
subclasses:



A hierarchy oI bicycle classes.
The syntax Ior creating a subclass is simple. At the beginning oI your class declaration, use the
0903/8 keyword, Iollowed by the name oI the class to inherit Irom:
class MountainBike extends Bicycle

// new Iields and methods deIining a mountain bike would go here

}
This gives MountainBike all the same Iields and methods as Bicycle, yet allows its code to
Iocus exclusively on the Ieatures that make it unique. This makes code Ior your subclasses easy
to read. However, you must take care to properly document the state and behavior that each
superclass deIines, since that code will not appear in the source Iile oI each subclass.
1.3.1 what should be inherited, behaviour or code?
Behavior and code hierarchies are rarely compatible with each other and are oIten nega- tively
correlated because shared behavior and shared code have diIIerent requirements. Consider a
stack and a double-ended queue (deque). A deque may be viewed as a stack with additional
operations and is thereIore a subclass oI a stack when behavior is the basis Ior inheritance.
How- ever, Irom the viewpoint oI implementation, a deque needs two list pointers in its data


structure while a stack needs only one. It is simpler to implement a stack in terms oI a deque
than a deque in terms oI a stack. Thus it is easier to have the code Ior a stack inherit Irom the
code Ior a deque than the other way round.
More generally, adding operations tends to complicate the data structure required to support the
operations, and it is easier Ior a simple data structure to inherit Irom a more complex one than
the other way around. Adding operations speciIied by a class M to a parent class P is modeled at
the level oI behavior by inheritance oI the behavior oI P by M. But the data structure oI M sup-
ports a broader set oI behaviors than that oI P and it is practical to let the code oI M be the
super- class and P the subclass Ior code inheritance.
1.4 Data Abstraction:
Abstraction is the process by which data and programs are deIined with a representation
similar to its pictorial meaning as rooted in the more complex realm oI human liIe and language
with their higher need oI summarization and categorization (semantics), while hiding away the
implementation details. Abstraction tries to reduce and Iactor out details so that the programmer
can Iocus on a Iew concepts at a time. A system can have several abstraction layers whereby
diIIerent meanings and amounts oI detail are exposed to the programmer. For example, low-
level abstraction layers expose details oI the hardware where the program is run, while high-
level layers deal with the business logic oI the program.
abstraction - a concept or idea not associated with any speci1ic instance.
Abstraction captures only those details about an object that are relevant to the current
perspective. The concept originated by analogy with abstraction in mathematics. The
mathematical technique oI abstraction begins with mathematical deIinitions, making it a more
technical approach than the general concept oI abstraction in philosophy. For example, in both
computing and in mathematics, numbers are concepts in the programming languages, as
Iounded in mathematics. Implementation details depend on the hardware and soItware, but this
is not a restriction because the computing concept oI number is still based on the mathematical
concept. The concept oI abstraction relates to the idea oI hiding data that is not needed Ior
presentation. The main idea behind data abstraction is to give a clear separation between
properties oI data type and the associated implementation details. This separation is achieved in
order that the properties oI the abstract data type are visible to the user interIace and the
10

implementation details are hidden. Thus, abstraction Iorms the basic platIorm Ior the creation oI
user-deIined data types called objects.
Data abstraction is the process oI reIining data to its essential Iorm. An Abstract Data Type is
deIined as a data type that is deIined in terms oI the operations that it supports and not in terms
oI its structure or implementation. In object-oriented programming language C, it is possible
to create and provide an interIace that accesses only certain elements oI data types. The
programmer can decide which user to give or grant access to and hide the other details. This
concept is called data hiding which is similar in concept to data abstraction.
In computer programming, abstraction can apply to control or to data Control abstraction is the
abstraction oI actions while data abstraction is that oI data structures.
O Control abstraction involves the use oI subprograms and related concepts control Ilows
O Data abstraction allows handling data bits in meaningIul ways. For example, it is the
basic motivation behind datatype.
One can regard the notion oI an object (Irom object-oriented programming) as an attempt to
combine abstractions oI data and code.
The same abstract deIinition can be used as a common interIace Ior a Iamily oI objects with
diIIerent implementations and behaviors but which share the same meaning. The inheritance
mechanism in object-oriented programming can be used to deIine an abstract class as the
common interIace.The recommendation that programmers use abstractions whenever suitable in
order to avoid duplication (usually oI code) is known as the abstraction principle. The
requirement that a programming language provide suitable abstractions is also called the
abstraction principle.
Data Abstraction increases the power oI programming language by creating user deIined data
types. Data Abstraction also represents the needed inIormation in the program without
presenting the details.For example, your program can make a call to the sort() Iunction without
knowing what algorithm the Iunction actually uses to sort the given values. In Iact, the
underlying implementation oI the sorting Iunctionality could change between releases oI the
library, and as long as the interIace stays the same, your Iunction call will still work.
In C we use classes to deIine our own abstract data types (ADT). You can use the cout object
oI class ostream to stream data to standard output like this:
11

include iostream~
using namespace std;

int main( )

cout "Hello C" endl;
return 0;
}
Here you don't need to understand how cout displays the text on the user's screen. You need
only know the public interIace and the underlying implementation oI cout is Iree to change.In
object-oriented programming theory, abstraction involves the Iacility to deIine objects that
represent abstract "actors" that can perIorm work, report on and change their state, and
"communicate" with other objects in the system. The term encapsulation reIers to the hiding oI
state details, but extending the concept oI data type Irom earlier programming languages to
associate behavior most strongly with the data, and standardizing the way that diIIerent data
types interact, is the beginning oI abstraction. When abstraction proceeds into the operations
deIined, enabling objects oI diIIerent types to be substituted, it is called polymorphism. When it
proceeds in the opposite direction, inside the types or classes, structuring them to simpliIy a
complex set oI relationships, it is called delegation or inheritance
Various object-oriented programming languages oIIer similar Iacilities Ior abstraction, all to
support a general strategy oI polymorphism in object-oriented programming, which includes the
substitution oI one type Ior another in the same or similar role. Although not as generally
supported, a conIiguration or image or package may predetermine a great many oI these
bindings at compile-time, link-time, or loadtime. This would leave only a minimum oI such
bindings to change at run-time.
Common Lisp Object $ystem or selI, Ior example, Ieature less oI a class-instance distinction
and more use oI delegation Ior polymorphism. Individual objects and Iunctions are abstracted
more Ilexibly to better Iit with a shared Iunctional heritage Irom Lisp.
1.4.1 Levels of abstraction
Computer science commonly presents levels (or, less commonly, layers) oI abstraction, wherein
each level represents a diIIerent model oI the same inIormation and processes, but uses a system
1

oI expression involving a unique set oI objects and compositions that apply only to a particular
domain. Each relatively abstract, "higher" level builds on a relatively concrete, "lower" level,
which tends to provide an increasingly "granular" representation. For example, gates build on
electronic circuits, binary on gates, machine language on binary, programming language on
machine language, applications and operating systems on programming languages. Each level is
embodied, but not determined, by the level beneath it, making it a language oI description that is
somewhat selI-contained.
Database systems
$ince many users oI database systems lack in-depth Iamiliarity with computer data-structures,
database developers oIten hide complexity through the Iollowing levels:

Data abstraction levels oI a database system
a) Physical level: The lowest level oI abstraction describes how a system actually stores
data. The physical level describes complex low-level data structures in detail.
b) Logical level: The next higher level oI abstraction describes what data the database
stores, and what relationships exist among those data. The logical level thus describes
an entire database in terms oI a small number oI relatively simple structures. Although
implementation oI the simple structures at the logical level may involve complex
physical level structures, the user oI the logical level does not need to be aware oI this
complexity. This reIerred to as Physical Data Independence. Database administrators,
who must decide what inIormation to keep in a database, use the logical level oI
abstraction.
c) View level: The highest level oI abstraction describes only part oI the entire database.
Even though the logical level uses simpler structures, complexity remains because oI
the variety oI inIormation stored in a large database. Many users oI a database system
do not need all this inIormation; instead, they need to access only a part oI the database.
1

The view level oI abstraction exists to simpliIy their interaction with the system. The
system may provide many views Ior the same database.
1.4.2 Layered architecture
The ability to provide a design oI diIIerent levels oI abstraction can
O simpliIy the design considerably
O enable diIIerent role players to eIIectively work at various levels oI abstraction
$ystems design and business process design can both use this. $ome design processes
speciIically generate designs that contain various levels oI abstraction.
Layered architecture partitions the concerns oI the application into stacked groups (layers). It is
a technique used in designing computer soItware, hardware, and communications in which
system or network components are isolated in layers so that changes can be made in one layer
without aIIecting the others
1.4.3 Types of Abstraction Differs:
There are two broad types oI abstraction:
O Iunctional abstraction
O data abstraction.
The main diIIerence between Iunctional abstraction and data abstraction is that Iunctional
abstraction reIers to a Iunction that can be used without taking into account how the Iunction is
implemented. Data abstraction reIers to the data that can be used without taking into account
how the data are stored. There is also a diIIerence in the way the access takes place in Iunctional
abstraction and data abstraction.
In Iunctional abstraction, access to the Iunction is provided through a speciIic interIace deIined
to invoke the Iunction. In contrast, in data abstraction, access to the data is provided through a
speciIic set oI operations deIined to examine and manipulate the data. For instance, when a
programmer is using C standard data types, this means that users are using the concept oI
data abstraction. When using data types, the users are not concerned with how the data is stored
but they are concerned with what operations are provided and what properties are supported.
1

1.4.4 Reasons for the need of Abstraction
a) Flexibility in approach:
By hiding data or abstracting details that are not needed Ior presentation, the programmer
achieves greater Ilexibility in approach.
b) Enhanced Security:
Abstraction gives access to data or details that are needed by users and hide the implementation
details, giving enhanced security to application.
c) Easier Replacement:
With the concept oI abstraction in object-oriented programming language, it is possible to
replace code without recompilation. This makes the process easier and saves time Ior users.
d) odular Approach:
In object-oriented programming language C, the abstraction concept helps users to divide the
project application into modules and test each oI them separately. Then all modules are
integrated and ultimately tested together. This approach makes the application development
easier.
There are various ways oI achieving abstraction in object-oriented programming language C.
One approach is to take modular based code that is broken apart into smaller segments, known
as Iunctions. This Iunctional or modular approach helps the code to be reused again and again
when needed. For example, a programmer might write a Iunction Ior computing an average and
another programmer might write a Iunction Ior computing salary. These Iunctions can be reused
when needed, by anyone. The modular based approach helps to centralize all data oI a similar
type, under the control oI a type module. DeIining module types allow the module to be an
abstract data type. In many other programming languages, there is a small drawback associated
with the approach to accessing module type.
In C, this problem is resolved through the concept oI Iriend Iunctions. Friend Iunctions
resolve the problem by associating with one oI the classes or some oI its members as Iriends oI
the other class.
1

The concept oI abstraction brings Iorth another related term known as encapsulation.
Encapsulation is the process oI combining or packaging data with Iunctions and thereby
allowing users to create a new data type. This new data type is termed abstract data type.
Though the new data type is similar to that oI built-in data type, it is termed abstract data type
because it enables users to abstract a concept Irom the problem space into the solution space.
Apart Irom the above, all the Ieatures that hold Ior built-in types also hold Ior abstract data
types. Type checking process that are perIormed Ior built-in types are also achieved in the same
way and level Ior abstract data types.
1.5 Data Encapsulation:
Data Encapsulation combines data and Iunctions into a single unit called Class. When using
Data Encapsulation, data is not accessed directly; it is only accessible through the Iunctions
present inside the class. Data Encapsulation enables the important concept oI data hiding
possible. Encapsulation is the term given to the process oI hiding all the details oI an object that
do not contribute to its essential characteristics.
Encapsulation hides the implementation details oI the object and the only thing that remains
externally visible is the interIace oI the object. (i.e.: the set oI all messages the object can
respond to)
Once an object is encapsulated, its implementation details are not immediately accessible any
more. Instead they are packaged and are only indirectly accessible via the interIace oI the
object. The only way to access such an encapsulated object is via message passing: one sends a
message to the object, and the object itselI selects the method by which it will react to the
message, determined by Iunctions.
Another Iorm oI encapsulation is called object based encapsulation. Object-based encapsulation
"packages" all the implementation details in the object. All data and the implementation oI all
methods operating on this data are incorporated into the same abstract entity representing the
object. However, with this type oI encapsulation an object can only make use oI its own
attributes and private resources. An object-based encapsulation module has no direct access to
the implementation details oI any oI its acquaintances. (The acquaintances oI an object are all
the objects a certain object has knowledge oI, or can directly reIer to).
The idea behind object oriented encapsulation is that objects can interact with one another
without really caring how each other does what it does.
1

Ior instance, iI you have a database object, and a network object which interact with each other.
the network object constantly requests inIormation Irom the database object, it doesn't really
care how the database object gets that inIormation, just as long as it gets it. one day, someone
decides that the database object is not running very eIIiciently, and overhauls the way the
database object stores and retrieves inIormation. the network object is unaIIected by this change
because it never cared in the Iirst place how the database object Iunction internally. had these
objects not been encapsulated in this manner, they may have both required changes.
Another advantage oI using object oriented encapsulation is Ior code re- usability. II you
encapsulate say a database object, it might have some internal method called "search." every
instance oI that object will now have the ability to search itselI Ior inIormation, and you've only
written the Iunction once. Inheritance is also a large part oI object oriented programming. this
also plays into code re-usability.
1.6 Polymorphism:
Polymorphism allows routines to use variables oI diIIerent types at diIIerent times. An operator
or Iunction can be given diIIerent meanings or Iunctions. Polymorphism reIers to a single
Iunction or multi-Iunctioning operator perIorming in diIIerent ways.
Polymorphism is the ability to use an operator or method in diIIerent ways. Polymorphism gives
diIIerent meanings or Iunctions to the operators or methods. Poly, reIerring to many, signiIies
the many uses oI these operators and methods. A single method usage or an operator
Iunctioning in many ways can be called polymorphism. Polymorphism reIers to codes,
operations or objects that behave diIIerently in diIIerent contexts.
Below is a simple example oI the above concept oI polymorphism:
6 10
The above reIers to integer addition. The same operator can be used with diIIerent meanings
with strings:
"ExIorsys" "Training"
The same operator can also be used Ior Iloating point addition:
1

.15 3.
Polymorphism is a powerIul Ieature oI the object oriented programming language C. A single
operator behaves diIIerently in diIIerent contexts such as integer, Iloat or strings reIerring the
concept oI polymorphism. The above concept leads to operator overloading. The concept oI
overloading is also a branch oI polymorphism. When the exiting operator or Iunction operates
on new data type it is overloaded. This Ieature oI polymorphism leads to the concept oI virtual
methods.
Polymorphism reIers to the ability to call diIIerent Iunctions by using only one type oI Iunction
call. $uppose a programmer wants to code vehicles oI diIIerent shapes such as circles, squares,
rectangles, etc. One way to deIine each oI these classes is to have a member Iunction Ior each
that makes vehicles oI each shape. Another convenient approach the programmer can take is to
deIine a base class named $hape and then create an instance oI that class. The programmer can
have array that hold pointers to all diIIerent objects oI the vehicle Iollowed by a simple loop
structure to make the vehicle, as per the shape desired, by inserting pointers into the deIined
array. This approach leads to diIIerent Iunctions executed by the same Iunction call.
Polymorphism is used to give diIIerent meanings to the same concept. This is the basis Ior
Virtual Iunction implementation.
In polymorphism, a single Iunction or an operator Iunctioning in many ways depends upon the
usage to Iunction properly. In order Ior this to occur, the Iollowing conditions must apply:
O All diIIerent classes must be derived Irom a single base class. In the above example, the
shapes oI vehicles (circle, triangle, rectangle) are Irom the single base class called
$hape.
O The member Iunction must be declared virtual in the base class. In the above example,
the member Iunction Ior making the vehicle should be made as virtual to the base class.
1.6.1 Features and Advantages of the concept of Polymorphism:
Applications are Easily Extendable:
Once an application is written using the concept oI polymorphism, it can easily be
extended, providing new objects that conIorm to the original interIace. It is unnecessary to
recompile original programs by adding new types. Only re-linking is necessary to exhibit the
new changes along with the old application. This is the greatest achievement oI C object-
1

oriented programming. In programming language, there has always been a need Ior adding and
customizing. By utilizing the concept oI polymorphism, time and work eIIort is reduced in
addition to making Iuture maintenance easier.
O Helps in reusability oI code.
O Provides easier maintenance oI applications.
O Helps in achieving robustness in applications.
1.6.2 Types of Polymorphism:
C provides three diIIerent types oI polymorphism.
O Virtual Iunctions
O Function name overloading
O Operator overloading
In addition to the above three types oI polymorphism, there exist other kinds oI polymorphism:
O run-time
O compile-time
O ad-hoc polymorphism
O parametric polymorphism
Other types oI polymorphism deIined:
Run-time :
The run-time polymorphism is implemented with inheritance and virtual Iunctions.
Compile-time :
The compile-time polymorphism is implemented with templates.
Ad-hoc polymorphism:
II the range oI actual types that can be used is Iinite and the combinations must be individually
speciIied prior to use, this is called ad-hoc polymorphism.
1

1.6.3 Parametric polymorphism:
II all code is written without mention oI any speciIic type and thus can be used transparently
with any number oI new types it is called parametric polymorphism.
In general, there are two main categories oI Polymorphism:
O Ad Hoc Polymorphism
O Pure Polymorphism
Overloading concepts Iall under the category oI Ad Hoc Polymorphism and Virtual methods.
Templates or parametric classes Iall under the category oI Pure Polymorphism.
1.7 Overloading:
Overloading is one type oI Polymorphism. It allows an object to have diIIerent meanings,
depending on its context. When an existing operator or Iunction begins to operate on new data
type, or class, it is understood to be overloaded.
The terms ``polymorphism'' and ``argument overloading'' reIer basically to the same thing, but
Irom slightly diIIerent points oI view. Polymorphism takes a pluralistic point oI view and notes
that several classes can each have a method with the same name. Argument overloading takes
the point oI the view oI the method name and notes that it can have diIIerent eIIects depending
on what kind oI object it applies to.
Operator overloading is similar. It reIers to the ability to turn operators oI the language (such as
`' and `' in C) into methods that can be assigned particular meanings Ior particular kinds oI
objects. Objective-C implements polymorphism oI method names, but not operator overloading.
For example, instead oI deIining an amount Consumed method Ior an Appliance object to report
the amount oI water it uses over a given period oI time, an amount Dispensed At Faucet method
Ior a Faucet to report virtually the same thing, and a cumulative Usage method Ior the Building
object to report the cumulative total Ior the whole building--requiring programmers to learn
three diIIerent names Ior what is conceptually the same operation--each class can simply have a
water Used method.
Polymorphism also permits code to be isolated in the methods oI diIIerent objects rather than be
gathered in a single Iunction that enumerates all the possible cases. This makes the code you
write more extensible and reusable. When a new case comes along, you don't have to
0

reimplement existing code, but only add a new class with a new method, leaving the code that's
already written alone.
For example, suppose you have code that sends a draw message to an object. Depending on the
receiver, the message might produce one oI two possible images. When you want to add a third
case, you don't have to change the message or alter existing code, but merely allow another
object to be assigned as the message receiver.
1.8 Reusability:
This term reIers to the ability Ior multiple programmers to use the same written and debugged
existing class oI data. This is a time saving device and adds code eIIiciency to the language.
Additionally, the programmer can incorporate new Ieatures to the existing class, Iurther
developing the application and allowing users to achieve increased perIormance. This time
saving Ieature optimizes code, helps in gaining secured applications and Iacilitates easier
maintenance on the application.
A principal goal oI object-oriented programming is to make the code you write as reusable as
possible--to have it serve many diIIerent situations and applications--so that you can avoid
reimplementing, even iI in only slightly diIIerent Iorm, something that's already been done.
Reusability is inIluenced by a variety oI diIIerent Iactors, including:
O How reliable and bug-Iree the code is
O How clear the documentation is
O How simple and straightIorward the programming interIace is
O How eIIiciently the code perIorms its tasks
O How Iull the Ieature set is
Clearly, these Iactors don't apply just to the object model. They can be used to judge the
reusability oI any code--standard C Iunctions as well as class deIinitions. EIIicient and well
documented Iunctions, Ior example, would be more reusable than undocumented and unreliable
ones.
Nevertheless, a general comparison would show that class deIinitions lend themselves to
reusable code in ways that Iunctions do not. There are various things you can do to make
Iunctions more reusable--passing data as arguments rather than assuming speciIically-named
1

global variables, Ior example. Even so, it turns out that only a small subset oI Iunctions can be
generalized beyond the applications they were originally designed Ior. Their reusability is
inherently limited in at least three ways:
O Function names are global variables; each Iunction must have a unique name (except
Ior those declared static). This makes it diIIicult to rely heavily on library code when
building a complex system. The programming interIace would be hard to learn and so
extensive that it couldn't easily capture signiIicant generalizations.
Classes, on the other hand, can share programming interIaces. When the same naming
conventions are used over and over again, a great deal oI Iunctionality can be packaged
with a relatively small and easy-to-understand interIace.
O Functions are selected Irom a library one at a time. It's up to programmers to pick and
choose the individual Iunctions they need.
In contrast, objects come as packages oI Iunctionality, not as individual methods and
instance variables. They provide integrated services, so users oI an object-oriented
library won't get bogged down piecing together their own solutions to a problem.
O Functions are typically tied to particular kinds oI data structures devised Ior a speciIic
program. The interaction between data and Iunction is an unavoidable part oI the
interIace. A Iunction is useIul only to those who agree to use the same kind oI data
structures it accepts as arguments.
Because it hides its data, an object doesn't have this problem. This is one oI the principal
reasons why classes can be reused more easily than Iunctions. An object's data is protected and
won't be touched by any other part oI the program. Methods can thereIore trust its integrity.
They can be sure that external access hasn't put it in an illogical or untenable state. This makes
an object data structure more reliable than one passed to a Iunction, so methods can depend on it
more. Reusable methods are consequently easier to write.
Moreover, because an object's data is hidden, a class can be reimplemented to use a diIIerent
data structure without aIIecting its interIace. All programs that use the class can pick up the new
version without changing any source code; no reprogramming is required.



References:-
Concepts and Paradigms oI Object-Oriented Programming Expansion oI Oct 400P$LA-
Keynote Talk Peter Wegner, Brown University.


G. Agha, P. Wegner, and A. Yonezawa, Proceedings oI Workshop on Object-Based Concurrent
Programming, $igplan Notices, April 1.


A. Yonezawa, ABCL: An Object-Oriented Concurrent $ystem, MIT Press 10.