Overview

Many people first learn to program using a language that is not object-oriented. Simple, non-OOP
programs may be one long list of commands. More complex programs will group lists of commands
into functions or subroutines each of which might perform a particular task. With designs of this sort, it is
common for the program's data to be accessible from any part of the program. As programs grow in size,
allowing any function to modify any piece of data means that bugs can have wide-reaching effects.

By contrast, the object-oriented approach encourages the programmer to place data where it is not
directly accessible by the rest of the program. Instead the data is accessed by calling specially written
'functions', commonly called methods, which are either bundled in with the data or inherited from "class
objects" and act as the intermediaries for retrieving or modifying that data. The programming construct
that combines data with a set of methods for accessing and managing that data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a
particular kind of complex data to be managed or perhaps to a real-world object or concept such as a
bank account, a hockey player, or a bulldozer. A program might well contain multiple copies of each type
of object, one for each of the real-world objects the program is dealing with. For instance, there could be
one bank account object for each real-world account at a particular bank. Each copy of the bank account
object would be alike in the methods it offers for manipulating or reading its data, but the data inside each
object would differ reflecting the different history of each account.

Objects can be thought of as wrapping their data within a set of functions designed to ensure that the data
is used appropriately, and to assist in that use. The object's methods will typically include checks and
safeguards that are specific to the type of data the object contains. An object can also offer simple-to-use,
standardized methods for performing particular operations on its data, while concealing the specifics of
how those tasks are accomplished. In this way alterations can be made to the internal structure or
methods of an object without requiring that the rest of the program be modified. This approach can also
be used to offer standardized methods across different types of objects. As an example, several different
types of objects might offer print methods. Each type of object might implement that print method in a
different way, reflecting the different kinds of data each contains, but all the different print methods might
be called in the same standardized manner from elsewhere in the program. These features become
especially useful when more than one programmer is contributing code to a project or when the goal is to
reuse code between projects.

Object-oriented programming has roots that can be traced to the 1960s. As hardware and software
became increasingly complex, manageability often became a concern. Researchers studied ways to
maintain software quality and developed object-oriented programming in part to address common
problems by strongly emphasizing discrete, reusable units of programming logic [citation needed]. The
technology focuses on data rather than processes, with programs composed of self-sufficient modules
("classes"), each instance of which ("objects") contains all the information needed to manipulate its own
data structure ("members"). This is in contrast to the existing modular programmingthat had been
dominant for many years that focused on the function of a module, rather than specifically the data, but
equally provided forcode reuse, and self-sufficient reusable units of programming logic,
enabling collaboration through the use of linked modules (subroutines). This more conventional approach,
which still persists, tends to consider data and behavior separately.

An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the

conventional model, in which a program is seen as a list of tasks (subroutines) to perform. In OOP, each
object is capable of receiving messages, processing data, and sending messages to other objects. Each
object can be viewed as an independent "machine" with a distinct role or responsibility. The actions (or
"methods") on these objects are closely associated with the object. For example, OOP data
structures tend to 'carry their own operators around with them' (or at least "inherit" them from a similar
object or class). In the conventional model, the data and operations on the data don't have a tight, formal
association.

[edit]History

The terms "objects" and "oriented" in something like the modern sense of object-oriented programming
seem to make their first appearance at MIT in the late 1950s and early 1960s. In the environment of
the artificial intelligence group, as early as 1960, "object" could refer to identified items (LISP atoms) with
properties (attributes);[1][2] Alan Kay was later to cite a detailed understanding of LISP internals as a strong
influence on his thinking in 1966.[3] Another early MIT example was Sketchpad created by Ivan
Sutherland in 1960-61; in the glossary of the 1963 technical report based on his dissertation about
Sketchpad, Sutherland defined notions of "object" and "instance" (with the class concept covered by
"master" or "definition"), albeit specialized to graphical interaction. [4] Also, an MIT ALGOL version, AED-0,
linked data structures ("plexes", in that dialect) directly with procedures, prefiguring what were later
termed "messages", "methods" and "member functions".[5][6]

Objects as a formal concept in programming were introduced in the 1960s in Simula 67, a major revision
of Simula I, a programming language designed for discrete event simulation, created by Ole-Johan
Dahl and Kristen Nygaard of the Norwegian Computing Center in Oslo.[7] Simula 67 was influenced
by SIMSCRIPT and Hoare's proposed "record classes".[5][8] Simula introduced the notion of classes and
instances or objects (as well as subclasses, virtual methods, coroutines, and discrete event simulation) as
part of an explicit programming paradigm. The language also used automatic garbage collection that had
been invented earlier for the functional programming language Lisp. Simula was used for physical
modeling, such as models to study and improve the movement of ships and their content through cargo
ports. The ideas of Simula 67 influenced many later languages, including Smalltalk, derivatives of LISP
(CLOS), Object Pascal, and C++.

The Smalltalk language, which was developed at Xerox PARC (by Alan Kay and others) in the 1970s,
introduced the term object-oriented programming to represent the pervasive use of objects and messages
as the basis for computation. Smalltalk creators were influenced by the ideas introduced in Simula 67, but
Smalltalk was designed to be a fully dynamic system in which classes could be created and modified
dynamically rather than statically as in Simula 67.[9] Smalltalk and with it OOP were introduced to a wider
audience by the August 1981 issue of Byte Magazine.

In the 1970s, Kay's Smalltalk work had influenced the Lisp community to incorporate object-based
techniques that were introduced to developers via the Lisp machine. Experimentation with various
extensions to Lisp (like LOOPS and Flavors introducing multiple inheritanceand mixins), eventually led to
the Common Lisp Object System (CLOS, a part of the first standardized object-oriented programming
language,ANSI Common Lisp), which integrates functional programming and object-oriented
programming and allows extension via a Meta-object protocol. In the 1980s, there were a few attempts to
design processor architectures that included hardware support for objects in memory but these were not
successful. Examples include the Intel iAPX 432 and the Linn Smart Rekursiv.

Object-oriented programming developed as the dominant programming methodology in the early and mid
1990s when programming languages supporting the techniques became widely available. These included
Visual FoxPro 3.0,[10][11][12] C++[citation needed], and Delphi[citation needed]. Its dominance was further enhanced by the
rising popularity of graphical user interfaces, which rely heavily upon object-oriented programming
techniques. An example of a closely related dynamic GUI library and OOP language can be found in
the Cocoaframeworks on Mac OS X, written in Objective-C, an object-oriented, dynamic messaging
extension to C based on Smalltalk. OOP toolkits also enhanced the popularity of event-driven
programming (although this concept is not limited to OOP). Some [who?] feel that association with GUIs (real
or perceived) was what propelled OOP into the programming mainstream.

At ETH Zürich, Niklaus Wirth and his colleagues had also been investigating such topics as data
abstraction and modular programming(although this had been in common use in the 1960s or
earlier). Modula-2 (1978) included both, and their succeeding design, Oberon, included a distinctive
approach to object orientation, classes, and such. The approach is unlike Smalltalk, and very unlike C++.

Object-oriented features have been added to many existing languages during that time,
including Ada, BASIC, Fortran, Pascal, and others. Adding these features to languages that were not
initially designed for them often led to problems with compatibility and maintainability of code.

More recently, a number of languages have emerged that are primarily object-oriented yet compatible
with procedural methodology, such asPython and Ruby. Probably the most commercially important recent
object-oriented languages are Visual Basic.NET (VB.NET) and C#, both designed for
Microsoft's .NET platform, and Java, developed by Sun Microsystems. Both frameworks show the benefit
of using OOP by creating an abstraction from implementation in their own way. VB.NET and C# support
cross-language inheritance, allowing classes defined in one language to subclass classes defined in the
other language. Java runs in a virtual machine, making it possible to run on all different operating
systems. VB.NET and C# make use of the Strategy pattern to accomplish cross-language inheritance,
whereas Java makes use of the Adapter pattern[citation needed].

Just as procedural programming led to refinements of techniques such as structured programming,

modern object-oriented software design methods include refinements [citation needed] such as the use of design
patterns, design by contract, and modeling languages (such as UML).

[edit]Fundamental concepts and features

See also:  List of object-oriented programming terms

A survey by Deborah J. Armstrong of nearly 40 years of computing literature identified a number of

"quarks", or fundamental concepts, found in the strong majority of definitions of OOP. [13]

Not all of these concepts are to be found in all object-oriented programming languages, and so object-
oriented programming that uses classes is sometimes called class-based programming. In
particular, prototype-based programming does not typically use classes. As a result, a significantly
different yet analogous terminology is used to define the concepts of object and instance.

Benjamin Cuire Pierce and some other researchers view as futile any attempt to distill OOP to a minimal
set of features. He nonetheless identifies fundamental features that support the OOP programming style
in most object-oriented languages:[14]

 Dynamic dispatch – when a method is invoked on an object, the object itself determines what
code gets executed by looking up the method at run time in a table associated with the object. This
feature distinguishes an object from an abstract data type (or module), which has a fixed (static)
implementation of the operations for all instances. It is a programming methodology that gives
modular component development while at the same time being very efficient.
 Encapsulation (or multi-methods, in which case the state is kept separate)
 Subtype polymorphism
 Object inheritance (or delegation)
 Open recursion – a special variable (syntactically it may be a keyword), usually
called this or self, that allows a method body to invoke another method body of the same object.
This variable is late-bound; it allows a method defined in one class to invoke another method that is
defined later, in some subclass thereof.
Similarly, in his 2003 book, Concepts in programming languages, John C. Mitchell identifies four main
features: dynamic dispatch,abstraction, subtype polymorphism, and inheritance.[15] Michael Lee Scott
in Programming Language Pragmatics considers only encapsulation, inheritance and dynamic dispatch.
[16]

[edit]Class
Main article:  Class (computer science)

A class is a template for an object, a user-defined datatype that contains variables,properties of an object.
A class defines abstract characteristics of a thing (object), including its characteristics
(its attributes, fields or properties) and the things it can
do (behaviors,methods, operations or features). One might say that a class is a blueprint or factory that
describes the nature of something. For example, the class Dog would consist of traits shared by all dogs,
such as breed and fur color (characteristics), and the ability to bark and sit (behaviors). Classes
provide modularity and structure in an object-oriented computer program. A class should typically be
recognizable to a non-programmer familiar with the problem domain, meaning that the characteristics of
the class should make sense in context. Also, the code for a class should be relatively self-contained
(generally using encapsulation). Collectively, the properties and methods defined by a class are
called members.

[edit]Instance
Main article:  Instance (computer science)

One can have an instance of a class; the instance is the actual object created at run-time. In programmer
vernacular, the Lassie object is an instance of the Dog class. The set of values of the attributes of a
particular object is called its state. The object consists of state and the behavior that's defined in the
object's classes.

[edit]Method
Main article:  Method (computer science)

Method is a set of procedural statements for achieving the desired result. It performs different kinds of
operations on different data types. In a programming language, methods (sometimes referred to as
"functions") are verbs. Lassie, being a Dog, has the ability to bark. So bark()is one of Lassie's
methods. She may have other methods as well, for
example sit() or eat() or walk() or save(Timmy). Within the program, using a method usually
affects only one particular object; all Dogs can bark, but you need only one particular dog to do the
barking.

[edit]Message passing
Main article:  Message passing
"The process by which an object sends data to another object or asks the other object to invoke a
method."[13] Also known to some programming languages as interfacing. For example, the object
called Breeder may tell the Lassie object to sit by passing a "sit" message that invokes Lassie's "sit"
method. The syntax varies between languages, for example: [Lassie sit] in Objective-C. In Java,
code-level message passing corresponds to "method calling". Some dynamic languages use double-
dispatch or multi-dispatch to find and pass messages.

[edit]Abstraction
Main article:  Abstraction (computer science)

Abstraction means grouping the common behaviors.

Abstraction refers to the act of representing essential features without including the background details or
explanations. Classes use the concept of abstraction and are defined as a list of abstract attributes.
Abstraction is a mechanism where we hide the implementation or another way of looking , we want to
achieve loose coupling.

[edit]Encapsulation
Main article:  Encapsulation (object-oriented programming)

Encapsulation conceals the functional details of a class from objects that send messages to it.

For example, the Dog class has a bark() method variable, data. The code for the bark() method
defines exactly how a bark happens (e.g., by inhale() and then exhale(), at a particular pitch and
volume). Timmy, Lassie's friend, however, does not need to know exactly how she barks. Encapsulation
is achieved by specifying which classes may use the members of an object. The result is that each object
exposes to any class a certain interface — those members accessible to that class. The reason for
encapsulation is to prevent clients of an interface from depending on those parts of the implementation
that are likely to change in the future, thereby allowing those changes to be made more easily, that is,
without changes to clients. For example, an interface can ensure that puppies can only be added to an
object of the class Dog by code in that class. Members are often specified
as public, protected or private, determining whether they are available to all classes, sub-classes or
only the defining class. Some languages go further: Java uses the default access modifier to restrict
access also to classes in the same package, C# and VB.NET reserve some members to classes in the
same assembly using keywords internal (C#) orFriend (VB.NET). Eiffel and C++ allow one to specify
which classes may access any member.

[edit]Inheritance
Main article:  Inheritance (object-oriented programming)
Inheritance allows the programmer to treat derived class members just like their parent class's members.
This type of relationship is called child-Parent or is-a relationship. "Subclasses" are more specialized
versions of a class, which inherit attributes and behaviors from their parent classes, and can introduce
their own.

For example, the class Dog might have sub-classes called Collie, Chihuahua,

and GoldenRetriever. In this case, Lassie would be an instance of the Collie subclass. Suppose
the Dog class defines a method called bark() and a property called furColor. Each of its sub-classes
(Collie, Chihuahua, and GoldenRetriever) will inherit these members, meaning that the
programmer only needs to write the code for them once.

Each subclass can alter its inherited traits. For example, the Collie subclass might specify that the
default furColor for a collie is brown-and-white. The Chihuahua subclass might specify that
the bark() method produces a high pitch by default. Subclasses can also add new members.
The Chihuahua subclass could add a method called tremble(). So an individual chihuahua instance
would use a high-pitchedbark() from the Chihuahua subclass, which in turn inherited the
usual bark() from Dog. The chihuahua object would also have thetremble() method,
but Lassie would not, because she is a Collie, not a Chihuahua. In fact, inheritance is an "a… is a"
relationship between classes, while instantiation is an "is a" relationship between an object and a
class: a Collie is a Dog ("a… is a"), but Lassie is aCollie ("is a"). Thus, the object
named Lassie has the methods from both classes Collie and Dog.

Multiple inheritance is inheritance from more than one ancestor class, neither of these ancestors being an
ancestor of the other. For example, independent classes could define Dogs and Cats, and
a Chimera object could be created from these two that inherits all the (multiple) behavior of cats and
dogs. This is not always supported, as it can be hard to implement.

[edit](Subtype) polymorphism
Main article:  Subtype polymorphism

Polymorphism is a process in which a class has all the state and behavior of another class.

More precisely, Polymorphism in object-oriented programming is the ability of objects belonging to

different data types to respond to calls ofmethods of the same name, each one according to an
appropriate type-specific behavior. One method, or an operator such as +, -, or *, can be abstractly
applied in many different situations. If a Dog is commanded to speak(), this may elicit a bark().
However, if a Pig is commanded to speak(), this may elicit an oink(). Each subclass overrides
the speak() method inherited from the parent classAnimal.

[edit]Decoupling
Decoupling allows for the separation of object interactions from classes and inheritance into distinct layers
of abstraction. A common use of decoupling is to polymorphically decouple the encapsulation, [clarification
needed]
 which is the practice of using reusable code to prevent discrete code modules from interacting with
each other. However, in practice decoupling often involves trade-offs with regard to which patterns of
change to favor. The science of measuring these trade-offs in respect to actual change in an objective
way is still in its infancy.[citation needed]

[edit]Formal definition
There have been several attempts at formalizing the concepts used in object-oriented programming. The
following concepts and constructs have been used as interpretations of OOP concepts:

 coalgebraic datatypes[dubious  –  discuss]

 abstract data types (which have existential types) allow the definition of modules but these do not
support dynamic dispatch
 recursive types
 encapsulated state
 Inheritance (object-oriented programming)
 records are basis for understanding objects if function literals can be stored in fields (like in
functional programming languages), but the actual calculi need be considerably more complex to
incorporate essential features of OOP. Several extensions of System F<: that deal with mutable objects
have been studied;[17] these allow both subtype polymorphism and parametric
polymorphism (generics)

Attempts to find a consensus definition or theory behind objects have not proven very successful
(however, see Abadi & Cardelli, A Theory of Objects[17] for formal definitions of many OOP concepts and
constructs), and often diverge widely. For example, some definitions focus on mental activities, and some
on mere program structuring. One of the simpler definitions is that OOP is the act of using "map" data
structures or arrays that can contain functions and pointers to other maps, all with some syntactic and
scoping sugar on top. Inheritance can be performed by cloning the maps (sometimes called
"prototyping"). OBJECT:=>> Objects are the run time entities in an object-oriented system. They may
represent a person, a place, a bank account, a table of data or any item that the program has to handle.

[edit]OOP languages
This section does not cite any references or sources.
Please help improve this article by adding citations to reliable sources. Unsourced material may
be challenged andremoved. (August 2009)

See also:  List of object-oriented programming languages

Simula (1967) is generally accepted as the first language to have the primary features of an object-
oriented language. It was created for making simulation programs, in which what came to be called
objects were the most important information representation. Smalltalk (1972 to 1980) is arguably the
canonical example, and the one with which much of the theory of object-oriented programming was
developed. Concerning the degree of object orientation, following distinction can be made:

 Languages called "pure" OO languages, because everything in them is treated consistently as an

object, from primitives such as characters and punctuation, all the way up to whole classes,
prototypes, blocks, modules, etc. They were designed specifically to facilitate, even enforce, OO
methods. Examples: Smalltalk, Eiffel, Ruby, JADE.
 Languages designed mainly for OO programming, but with some procedural elements.
Examples: C++, C#, Java, Scala, Python.
 Languages that are historically procedural languages, but have been extended with some OO
features. Examples: VB.NET (derived from VB), Fortran 2003, Perl, COBOL 2002, PHP, ABAP.
 Languages with most of the features of objects (classes, methods, inheritance, reusability), but in
a distinctly original form. Examples:Oberon (Oberon-1 or Oberon-2).
 Languages with abstract data type support, but not all features of object-orientation, sometimes
called object-based languages. Examples: Modula-2 (with excellent encapsulation and information
hiding), Pliant, CLU.
[edit]OOP in dynamic languages
In recent years, object-oriented programming has become especially popular in dynamic programming
languages. Python, Ruby and Groovyare dynamic languages built on OOP principles,
while Perl and PHP have been adding object oriented features since Perl 5 and PHP 4,
andColdFusion since version 6.

The Document Object Model of HTML, XHTML, and XML documents on the Internet have bindings to the

popular JavaScript/ECMAScriptlanguage. JavaScript is perhaps the best known prototype-based
programming language, which employs cloning from prototypes rather than inheriting from a class.
Another scripting language that takes this approach is Lua. Earlier versions of ActionScript (a partial
superset of the ECMA-262 R3, otherwise known as ECMAScript) also used a prototype-based object
model. Later versions of ActionScript incorporate a combination of classification and prototype-based
object models based largely on the currently incomplete ECMA-262 R4 specification, which has its roots
in an early JavaScript 2 Proposal. Microsoft's JScript.NET also includes a mash-up of object models
based on the same proposal, and is also a superset of the ECMA-262 R3 specification.

[edit]Design patterns
Challenges of object-oriented design are addressed by several methodologies. Most common is known
as the design patterns codified by Gamma  et al.. More broadly, the term "design patterns" can be used to
refer to any general, repeatable solution to a commonly occurring problem in software design. Some of
these commonly occurring problems have implications and solutions particular to object-oriented
development.

[edit]Inheritance and behavioral subtyping

See also:  Object oriented design

It is intuitive to assume that inheritance creates a semantic "is a" relationship, and thus to infer that
objects instantiated from subclasses can always be safely used instead of those instantiated from the
superclass. This intuition is unfortunately false in most OOP languages, in particular in all those that
allow mutable objects. Subtype polymorphism as enforced by the type checker in OOP languages (with
mutable objects) cannot guarantee behavioral subtyping in any context. Behavioral subtyping is
undecidable in general, so it cannot be implemented by a program (compiler). Class or object hierarchies
need to be carefully designed considering possible incorrect uses that cannot be detected syntactically.
This issue is known as the Liskov substitution principle.

[edit]Gang of Four design patterns

Main article:  Design pattern (computer science)

Design Patterns: Elements of Reusable Object-Oriented Software is an influential book published in 1995
by Erich Gamma, Richard Helm,Ralph Johnson, and John Vlissides, sometimes casually called the
"Gang of Four". Along with exploring the capabilities and pitfalls of object-oriented programming, it
describes 23 common programming problems and patterns for solving them. As of April 2007, the book
was in its 36th printing.

The book describes the following patterns:

 Creational patterns (5): Factory Method Pattern, Abstract Factory Pattern, Singleton

Pattern, Builder Pattern, Prototype Pattern
 Structural patterns (7): Adapter Pattern, Bridge Pattern, Composite Pattern, Decorator
Pattern, Facade Pattern, Flyweight Pattern, Proxy Pattern
 Behavioral patterns (11): Chain of Responsibility Pattern, Command Pattern, Interpreter
Pattern, Iterator Pattern, Mediator Pattern,Memento Pattern, Observer Pattern, State
Pattern, Strategy Pattern, Template Method Pattern, Visitor Pattern
[edit]Object-orientation and databases
Main articles:  Object-Relational impedance mismatch,  Object-relational mapping, and Object database
Both object-oriented programming and relational database management systems (RDBMSs) are
extremely common in software today. Sincerelational databases don't store objects directly (though some
RDBMSs have object-oriented features to approximate this), there is a general need to bridge the two
worlds. The problem of bridging object-oriented programming accesses and data patterns with relational
databases is known as Object-Relational impedance mismatch. There are a number of approaches to
cope with this problem, but no general solution without downsides. [18] One of the most common
approaches is object-relational mapping, as found in libraries like Java Data Objects andRuby on Rails'
ActiveRecord.

There are also object databases that can be used to replace RDBMSs, but these have not been as
technically and commercially successful as RDBMSs.

[edit]Matching real world

OOP can be used to translate from real-world phenomena to program elements (and vice versa). OOP
was even invented for the purpose of physical modeling in the Simula 67 language. However, not
everyone agrees that direct real-world mapping is facilitated by OOP (seeCriticisms section), or is even a
worthy goal; Bertrand Meyer argues in Object-Oriented Software Construction[19] that a program is not a
model of the world but a model of some part of the world; "Reality is a cousin twice removed". At the
same time, some principal limitations of OOP had been noted. [20] An example for a real world problem that
cannot be modeled elegantly with OOP techniques is the Circle-ellipse problem.

However, Niklaus Wirth (who popularized the adage now known as Wirth's law: "Software is getting
slower more rapidly than hardware becomes faster") said of OOP in his paper, "Good Ideas through the
Looking Glass", "This paradigm closely reflects the structure of systems 'in the real world', and it is
therefore well suited to model complex systems with complex behaviours" (contrast KISS principle).

However, it was also noted (e.g. in Steve Yegge's essay Execution in the Kingdom of Nouns[1]) that the
OOP approach of strictly prioritizing things (objects/nouns) before actions (methods/verbs) is a paradigm
not found in natural languages.[21] This limitation may lead for some real world modelling to
overcomplicated results compared e.g. to procedural approaches. [22]

[edit]OOP and control flow

OOP was developed to increase the reusability and maintainability of source code.[23] Transparent
representation of the control flow had no priority and was meant to be handled by a compiler. With the
increasing relevance of parallel hardware and multithreaded coding, developer transparent control flow
becomes more important, something hard to achieve with OOP. [24][25][26]

[edit]Responsibility vs. data-driven design

Responsibility-driven design defines classes in terms of a contract, that is, a class should be defined
around a responsibility and the information that it shares. This is contrasted by Wirfs-Brock and Wilkerson
with data-driven design, where classes are defined around the data-structures that must be held. The
authors hold that responsibility-driven design is preferable.

[edit]Criticism