Object-oriented programming: Difference between revisions

Revision as of 17:09, 17 January 2009

Latest revision as of 09:24, 29 August 2025

Line 1:

{{short description|Programming paradigmsparadigm based on objects}}

{{Use dmy dates|date=January 2020}}

[[File:Oop-uml-class-example.svg|frame|right|[[UML]] notation for a class. This Button class has [[Variable (computer science)|variables]] for data, and [[Method (computer programming)|functions]]. Through inheritance, a subclass can be created as a subset of the Button class. Objects are instances of a class.]]

'''Object-oriented programming''' ('''OOP''') is a [[programming paradigm]] thatbased useson the "[[Object (computer science)|objectsobject]]" and their interactions to design applications and computer programs. Programming techniques may include<ref featuresname=alanKayOnOO/> such– asa [[information hiding|encapsulationsoftware]], entity that [[moduleencapsulation (programming)|modularityencapsulates]], [[Polymorphism in object-oriented programming|polymorphismdata]], and [[InheritanceFunction (computer scienceprogramming)|inheritancefunction(s)]]. ItAn wasOOP not[[computer commonlyprogram]] usedconsists inof mainstreamobjects softwarethat applicationinteract developmentwith untilone the early 1990sanother.<ref>{{Cite Many modern [[programming language]]s now support OOP.journal

|last1=Kindler |first1=E.

|last2=Krivy |first2=I.

== Overview ==

|year=2011

Object-oriented programming can trace its roots to the 1960s. As hardware and software became increasingly complex, quality was often compromised. 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. The methodology focuses on data rather than processes, with programs composed of self-sufficient modules (objects) each containing all the information needed to manipulate its own data structure.

|title=Object-Oriented Simulation of systems with sophisticated control

|journal=International Journal of General Systems

|volume=40

|issue=3

|pages=313–343 |doi=10.1080/03081079.2010.539975

}}</ref><ref>{{Cite book |last1=Lewis |first1=John |last2=Loftus |first2=William |year=2008 |chapter=1.6: Object-Oriented Programming |title=Java Software Solutions |series=Foundations of Programming Design |edition=6th |publisher=Pearson Education Inc. |isbn=978-0-321-53205-3}}</ref> A [[programming language]] that provides OOP features is classified as an ''OOP language'' but as the set of features that contribute to OOP is contended, classifying a language as OOP and the degree to which it supports or is OOP, are debatable. As paradigms are not mutually exclusive, a language can be [[multi-paradigm]]; can be categorized as more than only OOP.

Sometimes, objects represent real-world things and processes in digital form.<ref>{{cite book |last1=Booch |first1=Grady |author1-link=Grady Booch |year=1986 |title=Software Engineering with Ada |publisher=Addison Wesley |isbn=978-0-8053-0608-8 |page=220 |url=https://en.wikiquote.org/wiki/Grady_Booch |quote=Perhaps the greatest strength of an object-oriented approach to development is that it offers a mechanism that captures a model of the real world.}}</ref> For example, a graphics program may have objects such as {{code|circle}}, {{code|square}}, and {{code|menu}}. An online shopping system might have objects such as {{code|shopping cart}}, {{code|customer}}, and {{code|product}}. [[Niklaus Wirth]] said, "This paradigm [OOP] closely reflects the structure of systems in the real world and is therefore well suited to model complex systems with complex behavior".<ref>{{cite journal

The [[Simula]] programming language was the first to introduce the concepts underlying object-oriented programming (objects, classes, subclasses, virtual methods, coroutines, garbage collection, and discrete event simulation) as a superset of [[ALGOL|Algol]]. Simula was used for physical modeling, such as models to study and improve the movement of ships and their content through cargo ports. [[Smalltalk]] was the first programming language to be called "object-oriented".

|last1=Wirth |first1=Niklaus |author1-link=Niklaus Wirth

|journal=[[IEEE Computer]]

|volume=39

|issue=1

|date=January 23, 2006

|pages=28–39

|title=Good ideas, through the looking glass

|series=Cover Feature

|doi=10.1109/MC.2006.20

|s2cid=6582369

|url=https://pdfs.semanticscholar.org/10bd/dc49b85196aaa6715dd46843d9dcffa38358.pdf |archive-url=https://web.archive.org/web/20161012215755/https://pdfs.semanticscholar.org/10bd/dc49b85196aaa6715dd46843d9dcffa38358.pdf |url-status=dead |archive-date=12 October 2016

}}</ref>

However, more often, objects represent abstract entities, like an open file or a unit converter. Not everyone agrees that OOP makes it easy to copy the real world exactly or that doing so is even necessary. [[Robert C. Martin|Bob Martin]] suggests that because classes are software, their relationships don't match the real-world relationships they represent.<ref>{{cite web |url=https://www.youtube.com/watch?v=zHiWqnTWsn4 |title=Uncle Bob SOLID principles |website=[[YouTube]] |date=2 August 2018}}</ref> [[Bertrand Meyer]] argues 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".{{sfn|Meyer|1997|p=230}} [[Steve Yegge]] noted that [[natural language]]s lack the OOP approach of naming a thing (object) before an action (method), as opposed to [[functional programming]] which does the reverse.<ref name="executioniKoN">{{Cite web |last1=Yegge |first1=Steve |date=30 March 2006 |title=Execution in the Kingdom of Nouns |access-date=3 July 2010 |publisher=steve-yegge.blogspot.com |url=http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html}}</ref> This can make an OOP solution more complex than one written via [[procedural programming]].<ref name="executioniKoN2">{{Cite web |last1=Boronczyk |first1=Timothy |date=11 June 2009 |title=What's Wrong with OOP |url=http://zaemis.blogspot.com/2009/06/whats-wrong-with-oop.html |publisher=zaemis.blogspot.com |access-date=3 July 2010}}</ref>

OOP may be seen as a collection of cooperating ''objects'', as opposed to the more conventional model, in which a program is seen as a list of tasks ([[subroutine]]s) to perform. In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects.

Notable languages with OOP support include [[Ada (programming language)|Ada]], [[ActionScript]], [[C++]], [[Common Lisp]], [[C Sharp (programming language)|C#]], [[Dart (programming language)|Dart]], [[Eiffel (programming language)|Eiffel]], [[Fortran#Fortran_2003|Fortran 2003]], [[Haxe]], [[Java (programming language)|Java]],{{sfn|Bloch|2018|loc=Foreword|pp=xi-xii}} [[JavaScript]], [[Kotlin (programming language)|Kotlin]], [[Logo (programming language)|Logo]], [[MATLAB]], [[Objective-C]], [[Object Pascal]], [[Perl]], [[PHP]], [[Python (programming language)|Python]], [[R (programming language)|R]], [[Raku (programming language)|Raku]], [[Ruby (programming language)|Ruby]], [[Scala (programming language)|Scala]], [[SIMSCRIPT]], [[Simula]], [[Smalltalk]], [[Swift (programming language)|Swift]], [[Vala (programming language)|Vala]] and [[Visual Basic (.NET)]].

Each object can be viewed as an independent machine with a distinct role or responsibility. The actions (or "[[operators]]") on the objects are closely associated with the object. For example, the [[data structures]] tend to carry their own operators around with them (or at least "inherit" them from a similar object or class). The conventional approach tends to consider data and behavior separate.

==History==

==Fundamental concepts==

A survey by Deborah J. Armstrong <ref name="ArmstrongQuarks">Armstrong, ''The Quarks of Object-Oriented Development''. In descending order of popularity, the "quarks" are: Inheritance, Object, Class, Encapsulation, Method, Message Passing, Polymorphism, Abstraction</ref> of nearly 40 years of computing literature identified a number of "quarks", or fundamental concepts, found in the strong majority of definitions of OOP. They are the following:

; [[Class (computer science)|Class]] : Defines the abstract characteristics of a thing (object), including the thing's characteristics (its '''attributes''', '''[[Field (computer science)|fields]]''' or '''[[Property (programming)|properties]]''') and the thing's behaviors (the '''things it can do''', or '''[[method (computer science)|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 <code>Dog</code> 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 (programming)|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 '''[[Information Hiding|encapsulation]]'''). Collectively, the properties and methods defined by a class are called '''members'''.

; [[Object (computer science)|Object]] : A pattern (exemplar) of a class. The class of <code>Dog</code> defines all possible dogs by listing the characteristics and behaviors they can have; the object <code>Lassie</code> is one particular dog, with particular versions of the characteristics. A <code>Dog</code> has fur; <code>Lassie</code> has brown-and-white fur.

; [[Instance (computer science)|Instance]] : One can have an instance of a class or a particular object. The instance is the actual object created at runtime. In programmer jargon, the <code>Lassie</code> object is an '''instance''' of the <code>Dog</code> class. The set of values of the attributes of a particular object is called its [[state (computer science)|state]]. The object consists of state and the behaviour that's defined in the object's class.

; [[Method (computer science)|Method]] : An object's abilities. In language, methods (sometimes referred to as "functions") are verbs. <code>Lassie</code>, being a <code>Dog</code>, has the ability to bark. So <code>bark()</code> is one of <code>Lassie</code>'s methods. She may have other methods as well, for example <code>sit()</code> or <code>eat()</code> or <code>walk()</code> or <code>save_timmy()</code>. Within the program, using a method usually affects only one particular object; all <code>Dog</code>s can bark, but you need only one particular dog to do the barking.

; [[Message passing]] : "The process by which an object sends data to another object or asks the other object to invoke a method." <ref name="ArmstrongQuarks"/> Also known to some programming languages as interfacing. For example, the object called <code>Breeder</code> may tell the <code>Lassie</code> object to sit by passing a "sit" message which invokes Lassie's "sit" method. The syntax varies between languages, for example: <code>[Lassie sit]</code> 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.

; [[Inheritance (computer science)|Inheritance]] : "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 <code>Dog</code> might have sub-classes called <code>Collie</code>, <code>Chihuahua</code>, and <code>GoldenRetriever</code>. In this case, <code>Lassie</code> would be an instance of the <code>Collie</code> subclass. Suppose the <code>Dog</code> class defines a method called <code>bark()</code> and a property called <code>furColor</code>. Each of its sub-classes (<code>Collie</code>, <code>Chihuahua</code>, and <code>GoldenRetriever</code>) 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 <code>Collie</code> class might specify that the default <code>furColor</code> for a collie is brown-and-white. The <code>Chihuahua</code> subclass might specify that the <code>bark()</code> method produces a high pitch by default. Subclasses can also add new members. The <code>Chihuahua</code> subclass could add a method called <code>tremble()</code>. So an individual chihuahua instance would use a high-pitched <code>bark()</code> from the <code>Chihuahua</code> subclass, which in turn inherited the usual <code>bark()</code> from <code>Dog</code>. The chihuahua object would also have the <code>tremble()</code> method, but <code>Lassie</code> would not, because she is a <code>Collie</code>, not a <code>Chihuahua</code>. 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''''' <code>Collie</code> ''is a'' <code>Dog</code> ("a... is a"), but <code>Lassie</code> ''is a'' <code>Collie</code> ("is a"). Thus, the object named <code>Lassie</code> has the methods from both classes <code>Collie</code> and <code>Dog</code>.

: [[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 <code>Dog</code>s and <code>Cat</code>s, and a <code>Chimera</code> object could be created from these two which inherits all the (multiple) behavior of cats and dogs. This is not always supported, as it can be hard both to implement and to use well.

; [[Abstraction (computer science)|Abstraction]] : Abstraction is simplifying complex reality by modelling classes appropriate to the problem, and working at the most appropriate level of inheritance for a given aspect of the problem.

: For example, <code>Lassie</code> the <code>Dog</code> may be treated as a <code>Dog</code> much of the time, a <code>Collie</code> when necessary to access <code>Collie</code>-specific attributes or behaviors, and as an <code>Animal</code> (perhaps the parent class of <code>Dog</code>) when counting Timmy's pets. <br />Abstraction is also achieved through [[Object composition|Composition]]. For example, a class <code>Car</code> would be made up of an Engine, Gearbox, Steering objects, and many more components. To build the <code>Car</code> class, one does not need to know how the different components work internally, but only how to [[Interface (computer science)|interface]] with them, i.e., send messages to them, receive messages from them, and perhaps make the different objects composing the class interact with each other.

; [[Information hiding|Encapsulation]] : Encapsulation conceals the functional details of a class from objects that send messages to it.

: For example, the <code>Dog</code> class has a <code>bark()</code> method. The code for the <code>bark()</code> method defines exactly how a bark happens (e.g., by <code>inhale()</code> and then <code>exhale()</code>, at a particular pitch and volume). Timmy, <code>Lassie</code>'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 (computer science)|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 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 <code>Dog</code> 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 (programming language)|Java]] uses the '''default''' access modifier to restrict access also to classes in the same package, [[C Sharp (programming language)|C#]] and [[Visual Basic .NET|VB.NET]] reserve some members to classes in the same assembly using keywords '''internal''' (C#) or '''Friend''' (VB.NET), and [[Eiffel (programming language)|Eiffel]] and [[C++]] allow one to specify which classes may access any member.

; [[Polymorphism (computer science)|Polymorphism]] : Polymorphism allows the programmer to treat derived class members just like their parent class' members. More precisely, [[Polymorphism in object-oriented programming]] is the ability of [[Object (computer science)|objects]] belonging to different [[data type]]s to respond to method calls of [[Method (computer science)|methods]] 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 <code>Dog</code> is commanded to <code>speak()</code>, this may elicit a <code>bark()</code>. However, if a <code>Pig<code> is commanded to <code>speak()</code>, this may elicit an <code>oink()</code>. They both inherit <code>speak()</code> from <code>Animal</code>, but their derived class methods override the methods of the parent class; this is Overriding Polymorphism. Overloading Polymorphism is the use of one method signature, or one operator such as "+", to perform several different functions depending on the implementation. The "+" operator, for example, may be used to perform integer addition, float addition, list concatenation, or string concatenation. Any two subclasses of <code>Number</code>, such as <code>Integer</code> and <code>Double</code>, are expected to add together properly in an OOP language. The language must therefore overload the addition operator, "+", to work this way. This helps improve code readability. How this is implemented varies from language to language, but most OOP languages support at least some level of overloading polymorphism. Many OOP languages also support [[Parametric Polymorphism]], where code is written without mention of any specific type and thus can be used transparently with any number of new types. [[Pointer (computing)|Pointer]]s are an example of a simple polymorphic routine that can be used with many different types of objects.<ref>B. Stroustrup, The C++ Programming Language, 3rd-ed., p. 158</ref>

; [[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, which is the practice of using reusable code to prevent discrete code modules from interacting with each other.

The idea of "objects" in programming began with the [[artificial intelligence]] group at [[Massachusetts Institute of Technology]] (MIT) in the late 1950s and early 1960s. Here, "object" referred to [[Lisp (programming language)|LISP]] atoms with identified properties (attributes).<ref>{{Cite journal |last1=McCarthy |first1=J. |author1-link=John McCarthy (computer scientist) |last2=Brayton |first2=R. |last3=Edwards |first3=D. |last4=Fox |first4=P. |author4-link=Phyllis Fox |last5=Hodes |first5=L. |author5-link=Louis Hodes |last6=Luckham |first6=D. |author6-link=David Luckham |last7=Maling |first7=K. |last8=Park |first8=D. |author8-link=David Park (computer scientist) |last9=Russell |first9=S. |author9-link=Steve Russell (computer scientist) |date=March 1969 |title=LISP I Programmers Manual |url=http://history.siam.org/sup/Fox_1960_LISP.pdf |url-status=dead |journal=Computation Center and Research Laboratory of Electronics |publisher=Artificial Intelligence Group, [[M.I.T. Computation Center]] and Research Laboratory |page=88f |archive-url=https://web.archive.org/web/20100717111134/http://history.siam.org/sup/Fox_1960_LISP.pdf |archive-date=17 July 2010 |quote=In the local M.I.T. patois, association lists [of atomic symbols] are also referred to as "property lists", and atomic symbols are sometimes called "objects". |place=[[Boston]], [[Massachusetts]]}}</ref><ref>{{Cite book

Not all of the above concepts are to be found in all object-oriented programming languages, and so object-oriented programming that uses classes is called sometimes [[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''.

|last1=McCarthy

|first1=John

|author1-link=John McCarthy (computer scientist)

|last2=Abrahams

|first2=Paul W.

|last3=Edwards

|first3=Daniel J.

|last4=Hart

|first4=Swapnil D.

|last5=Levin

|first5=Michael I.

|year=1962

|url=https://archive.org/details/lisp15programmer00john/page/105

|title=LISP 1.5 Programmer's Manual

|publisher=[[MIT Press]]

|page=[https://archive.org/details/lisp15programmer00john/page/105 105]

|isbn=978-0-262-13011-0

|quote=Object – a synonym for atomic symbol

|df=dmy-all

}}</ref>

Another early example was [[Sketchpad]] created by [[Ivan Sutherland]] at MIT in 1960–1961. In the glossary of his technical report, Sutherland defined terms like "object" and "instance" (with the class concept covered by "master" or "definition"), albeit specialized to graphical interaction.<ref>{{cite conference

|author=[[Ivan E. Sutherland]]

|title=Sketchpad: a man-machine graphical communication system

|conference=AFIPS '63 (Spring): Proceedings of the May 21–23, 1963 Spring Joint Computer Conference

|publisher=AFIPS Press

|date=May 1963

|pages=329–346

|doi=10.1145/1461551.1461591|doi-access=free}}

</ref> Later, in 1968, AED-0, MIT's version of the [[ALGOL]] programming language, connected data structures ("plexes") and procedures, prefiguring what were later termed "messages", "methods", and "member functions".<ref name=simuladev>{{cite journal

|last1=Nygaard |first1=Kristen |author1-link=Kristen Nygaard

|last2=Dahl |first2=Ole-Johan |author2-link=Ole-Johan Dahl

|date=August 1, 1978

|title=The development of the SIMULA languages

|journal=[[ACM SIGPLAN Notices]]

|volume=13

|issue=8

|pages=245–272

|doi=10.1145/960118.808391

|doi-access=free

}}

</ref><ref>

{{Cite web

|last1=Ross |first1=Doug

|title=The first software engineering language

|work=LCS/AI Lab Timeline

|publisher=MIT Computer Science and Artificial Intelligence Laboratory

|url=http://www.csail.mit.edu/timeline/timeline.php?query=event&id=19

|access-date=13 May 2010}}

</ref>

Topics such as [[data abstraction]] and [[modular programming]] were common points of discussion at this time.

Meanwhile, in Norway, [[Simula]] was developed during the years 1961–1967.<ref name=simuladev/> Simula introduced essential object-oriented ideas, such as [[Class (computer programming)|classes]], inheritance, and [[Dynamic binding (computing)|dynamic binding]].<ref name="auto">{{Cite journal|last1=Holmevik|first1=Jan Rune|title=Compiling Simula: A historical study of technological genesis|journal=[[IEEE Annals of the History of Computing]]|volume=16|issue=4|pages=25–37|date=Winter 1994|url=http://www.idi.ntnu.no/grupper/su/publ/simula/holmevik-simula-ieeeannals94.pdf |doi=10.1109/85.329756 |s2cid=18148999 |access-date=3 March 2018 |archive-date=30 August 2017 |archive-url=https://web.archive.org/web/20170830065454/http://www.idi.ntnu.no/grupper/su/publ/simula/holmevik-simula-ieeeannals94.pdf |url-status=dead}}</ref>

==History==

Simula was used mainly by researchers involved with [[physical modelling]], like the movement of ships and their content through cargo ports.<ref name="auto"/> Simula is generally accepted as being the first language with the primary features and framework of an object-oriented language.<ref>{{cite journal |last1=Madsen |first1=Ole Lehrman |title=Kristen Nygaard |journal=A.M. Turing Award Laureates |url=https://amturing.acm.org/award_winners/nygaard_5916220.cfm |access-date=4 February 2025}}</ref>

{{Quote box

The concept of objects and instances in computing had its first major breakthrough with the [[PDP-1]] system at [[MIT]] which was probably the earliest example of capability based architecture. Another early ''example'' was [[Sketchpad]] made by [[Ivan Sutherland]] in 1963; however, this was an application and not a [[programming paradigm]].

|quote=I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning – it took a while to see how to do messaging in a programming language efficiently enough to be useful).

Objects as programming entities were introduced in the 1960s in [[Simula|Simula 67]], a programming language designed for making simulations, created by [[Ole-Johan Dahl]] and [[Kristen Nygaard]] of the [[Norwegian Computing Center]] in [[Oslo]]. (Reportedly, the story is that they were working on ship simulations, and were confounded by the combinatorial explosion of how the different attributes from different ships could affect one another. The idea occurred to group the different types of ships into different classes of objects, each class of objects being responsible for defining its ''own'' [[data]] and [[behavior]].){{Fact|date=February 2008}} Such an approach was a simple extrapolation of concepts earlier used in ''analog'' programming. On ''analog'' computers, mapping from real-world phenomena/objects to analog phenomena/objects (and conversely), was (and is) called 'simulation'. Simula not only introduced the notion of classes, but also of instances of classes, which is probably the first explicit use of those notions. The ideas of [[Simula|Simula 67]] influenced many later languages, especially Smalltalk and derivatives of [[Lisp programming language|Lisp]] and [[Pascal programming language|Pascal]]. <!-- Is this right? Surely not original, non-OO Pascal? -->

|author=Alan Kay

|source=<ref name=alanKayOnOO/>

|width=50%

}}

Influenced by both MIT and Simula, [[Alan Kay]] began developing his own ideas in November 1966. He would go on to create [[Smalltalk]], an influential OOP language. By 1967, Kay was already using the term "object-oriented programming" in conversation.<ref name=alanKayOnOO/> Although sometimes called the "father" of OOP,<ref>{{cite book |last1=Butcher |first1=Paul |title=Seven Concurrency Models in Seven Weeks: When Threads Unravel |date=30 June 2014 |publisher=Pragmatic Bookshelf |isbn=978-1-68050-466-8 |page=204 |url=https://books.google.com/books?id=Xg9QDwAAQBAJ&pg=PT204 |language=en}}</ref> Kay has said his ideas differ from how OOP is commonly understood, and has implied that the computer science establishment did not adopt his notion.<ref name=alanKayOnOO>{{Cite web |url=http://www.purl.org/stefan_ram/pub/doc_kay_oop_en |title=Dr. Alan Kay on the Meaning of "Object-Oriented Programming" |year=2003 |access-date=11 February 2010}}</ref>

The [[Smalltalk]] language, which was developed at [[Xerox PARC]] 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|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|Simula 67]]<ref name="st">{{cite web|first=Alan|last=Kay|url=http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html|title=The Early History of Smalltalk|accessdate=2007-09-13}}</ref>. Smalltalk and with it OOP were introduced to a wider audience by the August 1981 issue of [[Byte (magazine)|Byte magazine]].

A 1976 MIT memo co-authored by [[Barbara Liskov]] lists [[Simula 67]], [[CLU (programming language)|CLU]], and [[Alphard (programming language)|Alphard]] as object-oriented languages, but does not mention Smalltalk.<ref>{{cite tech report |last1=Jones |first1=Anita K. |last2=Liskov|first2=Barbara H. |date=April 1976 |title=An Access Control Facility for Programming Languages |institution=MIT |number=CSG Memo 137|url=http://csg.csail.mit.edu/CSGArchives/memos/Memo-137.pdf}}</ref>

In the 1970s, the first version of the [[Smalltalk]] programming language was developed at [[Xerox PARC]] by [[Alan Kay]], [[Dan Ingalls]] and [[Adele Goldberg (computer scientist)|Adele Goldberg]]. Smalltalk-72 was notable for use of objects at the language level and its graphical development environment.<ref name="Bertrand Meyer 2009 329">{{Cite book|title=Touch of Class: Learning to Program Well with Objects and Contracts|author=Bertrand Meyer|publisher=Springer Science & Business Media|year=2009|isbn=978-3-540-92144-8|pages=329|bibcode=2009tclp.book.....M}}</ref> Smalltalk was a fully dynamic system, allowing users to create and modify classes as they worked.<ref>{{cite journal

In the 1970s, Kay's Smalltalk work had influenced the [[Lisp (programming language)#Language innovations|Lisp community]] to incorporate [[Lisp (programming language)#Object systems|object-based techniques]] which were introduced to developers via the [[Lisp machine]]. In the 1980s, there were a few attempts to design processor architectures which included hardware support for objects in memory but these were not successful. Examples include the [[Intel iAPX 432]] and the [[Linn Products|Linn Smart]] [[Rekursiv]].

|title=The early history of Smalltalk

|author=[[Alan C. Kay]]

|journal=[[ACM SIGPLAN Notices]]

|volume=28

|issue=3

|pages=69–95

|date=March 1993

|doi=10.1145/155360.155364

|doi-access=free

}}

</ref> Much of the theory of OOP was developed in the context of Smalltalk, for example multiple inheritance.<ref>{{cite report |last1=Borning |first1=Alan Hamilton |date=1979 |title=Thinglab: a constraint-oriented simulation laboratory |url=https://constraints.cs.washington.edu/ui/thinglab-tr.pdf |publisher=Stanford University}}</ref>

In the late 1970s and 1980s, OOP rose to prominence. The [[Flavors (programming language)|Flavors]] object-oriented Lisp was developed starting 1979, introducing [[multiple inheritance]] and [[mixin]]s.<ref>{{cite conference |last1=Moon |first1=David A. |author1-link=David A. Moon |date=June 1986 |title=Object-Oriented Programming with Flavors |book-title=Conference proceedings on Object-oriented Programming Systems Languages and Applications |pages=1–8 |isbn=978-0-89791-204-4 |conference=[[OOPSLA]] '86 |doi=10.1145/28697.28698 |s2cid=17150741 |url=https://www.cs.tufts.edu/comp/150FP/archive/david-moon/flavors.pdf |access-date=2022-03-17}}</ref> In August 1981, [[Byte Magazine]] highlighted Smalltalk and OOP, introducing these ideas to a wide audience.<ref>{{cite news |title=Introducing the Smalltalk Zoo |url=https://computerhistory.org/blog/introducing-the-smalltalk-zoo-48-years-of-smalltalk-history-at-chm/ |work=CHM |date=17 December 2020 |language=en}}</ref> LOOPS, the object system for [[Interlisp]]-D, was influenced by Smalltalk and Flavors, and a paper about it was published in 1982.<ref>{{cite conference |title=LOOPS: data and object oriented Programming for Interlisp|date=1982|conference=European AI Conference|last1=Bobrow|first1=D. G.|last2=Stefik|first2=M. J|url=https://www.markstefik.com/wp-content/uploads/2011/04/1982-Bobrow-Stefik-Data-Object-Pgming.pdf}}</ref> In 1986, the first ''Conference on Object-Oriented Programming, Systems, Languages, and Applications'' ([[OOPSLA]]) was attended by 1,000 people. This conference marked the start of efforts to consolidate Lisp object systems, eventually resulting in the [[Common Lisp Object System]]. In the 1980s, there were a few attempts to design [[Processor design|processor architectures]] that included [[Computer hardware|hardware]] support for objects in [[Computer memory|memory]], but these were not successful. Examples include the [[Intel iAPX 432]] and the [[Linn Products|Linn Smart]] [[Rekursiv]].

Object-oriented programming developed as the dominant programming methodology during the mid-1990s, largely due to the influence of [[C++]]{{Fact|date=April 2007}}. Its dominance was further enhanced by the rising popularity of [[graphical user interface]]s, for which object-oriented programming seems to be well-suited. An example of a closely related dynamic GUI library and OOP language can be found in the [[Cocoa (software)|Cocoa]] frameworks on [[Mac OS X]], written in [[Objective C programming language|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 feel that association with GUIs (real or perceived) was what propelled OOP into the programming mainstream.

In the mid-1980s, new object-oriented languages like [[Objective-C]], [[C++]], and [[Eiffel language|Eiffel]] emerged. Objective-C was developed by [[Brad Cox]], who had used Smalltalk at [[ITT Inc.]] [[Bjarne Stroustrup]] created [[C++]] based on his experience using Simula for his PhD thesis.<ref name="Bertrand Meyer 2009 329"/> [[Bertrand Meyer]] produced the first design of the [[Eiffel language]] in 1985, which focused on software quality using a [[design by contract]] approach.{{sfn|Meyer|1997}}

At [[ETH Zürich]], [[Niklaus Wirth]] and his colleagues had also been investigating such topics as [[data abstraction]] and [[modularity (programming)|modular programming]]. [[Modula-2]] included both, and their succeeding design, [[Oberon programming language|Oberon]], included a distinctive approach to object orientation, classes, and such. The approach is unlike Smalltalk, and very unlike C++.

In the 1990s, OOP became the main way of programming, especially as more languages supported it. These included [[Visual FoxPro]] 3.0,<ref>1995 (June) [[Visual FoxPro]] 3.0, FoxPro evolves from a procedural language to an object-oriented language. Visual FoxPro 3.0 introduces a database container, seamless client/server capabilities, support for ActiveX technologies, and OLE Automation and null support. [http://www.foxprohistory.org/foxprotimeline.htm#summary_of_fox_releases Summary of Fox releases]</ref><ref>1995 Reviewers Guide to Visual FoxPro 3.0: [http://www.dfpug.de/loseblattsammlung/migration/whitepapers/vfp_rg.htm DFpug.de]</ref> [[C++]],<ref>{{Cite book|url=https://books.google.com/books?id=MHmqfSBTXsAC&pg=PA16|title=Object Oriented Programming with C++, 1E|isbn=978-81-259-2532-3|last1=Khurana|first1=Rohit|date=1 November 2009|publisher=Vikas Publishing House Pvt Limited}}</ref> and [[Delphi (software)|Delphi]]{{Citation needed|date=February 2010}}. OOP became even more popular with the rise of [[graphical user interface]]s, which used objects for buttons, menus and other elements. One well-known example is Apple's [[Cocoa (software)|Cocoa]] framework, used on [[macOS]] and written in [[Objective-C]]. OOP toolkits also enhanced the popularity of [[event-driven programming]].{{Citation needed|date=February 2025}}

Object-oriented features have been added to many existing languages during that time, including [[Ada programming language|Ada]], [[BASIC]], [[Fortran]], [[Pascal programming language|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.

At [[ETH Zürich]], [[Niklaus Wirth]] and his colleagues created new approaches to OOP. [[Modula-2]] (1978) and [[Oberon (programming language)|Oberon]] (1987), included a distinctive approach to object orientation, classes, and type checking across module boundaries. Inheritance is not obvious in Wirth's design since his nomenclature looks in the opposite direction: It is called type extension and the viewpoint is from the parent down to the inheritor.

In the past decade [[Java (programming language)|Java]] has emerged in wide use partially because of its similarity to [[C (programming language)|C]] and to [[C++]], but perhaps more importantly because of its implementation using a [[virtual machine]] that is intended to run code unchanged on many different platforms. This last feature has made it very attractive to larger development shops with heterogeneous environments. Microsoft's [[.NET Framework|.NET]] initiative has a similar objective and includes/supports several new languages, or variants of older ones with the important caveat that it is, of course, restricted to the [[Microsoft]] platform.

Many programming languages that were initially developed before OOP was popular have been augmented with object-oriented features, including [[Ada (programming language)|Ada]], [[BASIC]], [[Fortran]], [[Pascal (programming language)|Pascal]], and [[COBOL]].

More recently, a number of languages have emerged that are primarily object-oriented yet compatible with procedural methodology, such as [[Python (programming language)|Python]] and [[Ruby programming language|Ruby]]. Besides Java, probably the most commercially important recent object-oriented languages are [[Visual Basic .NET]] (VB.NET) and [[C Sharp (programming language)|C#]], both designed for Microsoft's [[.NET Framework|.NET]] platform. VB.NET and C# both support cross-language inheritance, allowing classes defined in one language to subclass classes defined in the other language. <!-- If this is about [[A#.NET, it is hype, an in any case it needs backing up: Another new language, named A# is being developed by students. It is stated that this language will revolutionize Object-Oriented Programming as we know it. The language is still very much in the works with no information available on the mother-developer of the language itself. -->

==Features==

Recently many universities have begun to teach Object-oriented design in introductory computer science classes.

{{Anchor|Object-oriented source code}}

{{See also|Comparison of programming languages (object-oriented programming)|List of object-oriented programming terms}}

The OOP features provided by languages varies. Below are some common features of OOP languages.<ref name="ArmstrongQuarks">Deborah J. Armstrong. ''The Quarks of Object-Oriented Development''. A survey of nearly 40 years of computing literature identified several fundamental concepts found in the large majority of definitions of OOP, in descending order of popularity: Inheritance, Object, Class, Encapsulation, Method, Message Passing, Polymorphism, and Abstraction.</ref><ref>[[John C. Mitchell]], ''Concepts in programming languages'', Cambridge University Press, 2003, {{ISBN|0-521-78098-5}}, p.278. Lists: Dynamic dispatch, abstraction, subtype polymorphism, and inheritance.</ref><ref>Michael Lee Scott, ''Programming language pragmatics'', Edition 2, Morgan Kaufmann, 2006, {{ISBN|0-12-633951-1}}, p. 470. Lists encapsulation, inheritance, and dynamic dispatch.</ref><ref name="pierce">{{Cite book|last1=Pierce|first1=Benjamin|title=Types and Programming Languages|publisher=MIT Press|year=2002|isbn=978-0-262-16209-8|title-link=Types and Programming Languages}}, section 18.1 "What is Object-Oriented Programming?" Lists: Dynamic dispatch, encapsulation or multi-methods (multiple dispatch), subtype polymorphism, inheritance or delegation, open recursion ("this"/"self")</ref> Comparing OOP with other styles, like [[relational programming]], is difficult because there isn't a clear, agreed-upon definition of OOP.<ref name="DatePage650">C. J. Date, Introduction to Database Systems, 6th-ed., Page 650</ref>

===Encapsulation===

Just as [[procedural programming]] led to refinements of techniques such as [[structured programming]], modern object-oriented software design methods include refinements such as the use of [[design pattern (computer science)|design patterns]], [[design by contract]], and [[modeling language]]s (such as [[Unified Modeling Language|UML]]).

An object [[Encapsulation (computer programming)|encapsulates]] [[Field (computer science) |fields]] and [[Method (computer programming) |method]]s. A field (a.k.a. attribute or property) contains information (a.k.a. state) as a [[variable (computer science) |variable]]. A method (a.k.a. [[function (programming) |function]] or action) defines behavior via logic code. Encapsulation is about keeping [[Cohesion (computer science)|related]], code together.

===Information hiding===

==OOP in scripting==

[[Information hiding]] is organizing code so that it is accessible only to the code that needs it; not to the rest of the [[codebase]]. The internal details of an object are hidden from the outside code, allowing for changing how an object works without affecting its interface and therefore other code. Hiding information helps prevent problems when changing the code.<ref>{{Cite book |last1=McDonough |first1=James E. |title=Object-Oriented Design with ABAP: A Practical Approach |date=2017 |publisher=[[Apress]] |isbn=978-1-4842-2837-1 |___location= |chapter=Encapsulation |doi=10.1007/978-1-4842-2838-8 |via=[[O'Reilly Media|O'Reilly]]}}</ref> Objects act as a barrier between their internal workings and external, consuming code. Consuming code can only interact with an object via its public members.

In recent years, object-oriented programming has become especially popular in [[scripting programming language]]s. [[Python (programming language)|Python]] and [[Ruby programming language|Ruby]] are scripting languages built on OOP principles, while [[Perl]] and [[PHP]] have been adding object oriented features since Perl 5 and PHP 3, and [[ColdFusion]] since version 6.

Some programming languages, like Java, provide information hiding via visibility key words ({{code|private}} and {{code|public}}).{{sfn|Bloch|2018|loc=Chapter §4 Item15 Minimize the accessibility of classes and members|pp=73-77}} Some languages don't provide a visibility feature, but developers might follow a convention such as starting a private member name with an underscore. Intermediate levels of access also exist, such as Java's {{code|protected}} keyword, (which allows access from the same class and its subclasses, but not objects of a different class), and the {{code|internal}} keyword in C#, Swift, and Kotlin, which restricts access to files within the same module.<ref>{{Cite web |date=2023-01-05 |title=What is Object Oriented Programming (OOP) In Simple Words? – Software Geek Bytes |url=https://softwaregeekbytes.com/object-oriented-programming-simple-words/ |access-date=2023-01-17 |language=en-US}}{{Dead link|date=July 2025 |bot=InternetArchiveBot |fix-attempted=yes}}</ref>

The [[Document Object Model]] of [[HTML]], [[XHTML]], and [[XML]] documents on the Internet have bindings to the popular [[JavaScript]]/[[ECMAScript]] language. JavaScript is perhaps the best known [[prototype-based programming]] language which employs cloning from prototypes rather than inheriting from a class. Another popular scripting language that exploits this approach is [[Lua (programming language)|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.

Supporters of information hiding and data abstraction say it makes code easier to reuse and intuitively represents real-world situations.<ref name="Luca1985">{{Cite journal |last1=Cardelli |first1=Luca |last2=Wegner |first2=Peter |date=1985-12-10 |title=On understanding types, data abstraction, and polymorphism |journal=ACM Computing Surveys |language=en |volume=17 |issue=4 |pages=471–523 |doi=10.1145/6041.6042 |issn=0360-0300|doi-access=free}}</ref><ref>{{cite book|last1=Jacobsen|first1=Ivar|title=Object Oriented Software Engineering|year=1992|publisher=Addison-Wesley ACM Press|isbn=978-0-201-54435-0|pages=[https://archive.org/details/objectorientedso00jaco/page/43 43–69]|author2=Magnus Christerson|author3=Patrik Jonsson|author4=Gunnar Overgaard|url=https://archive.org/details/objectorientedso00jaco/page/43}}</ref> However, others argue that OOP does not enhance readability or modularity.<ref name="badprop"/><ref name="armstrongjoe"/> [[Eric S. Raymond]] has written that OOP languages tend to encourage thickly layered programs that destroy transparency.<ref name="Eric S. Raymond 2003">{{cite web|url=http://www.catb.org/esr/writings/taoup/html/unix_and_oo.html|title=The Art of Unix Programming: Unix and Object-Oriented Languages|last1=Raymond|first1=Eric S.|date=2003|access-date=6 August 2014}}</ref> Raymond compares this unfavourably to the approach taken with [[Unix]] and the [[C (programming language)|C]] language.<ref name="Eric S. Raymond 2003"/>

==Problems and patterns==

There are a number of programming challenges which a developer encounters regularly in object-oriented design. There are also widely accepted solutions to these problems. The best known are the [[Design Patterns|design patterns codified by Gamma ''et al'']], but in a broader sense the term "[[design pattern (computer science)|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.

[[SOLID]] includes the [[open/closed principle]], which says that classes and functions should be "open for extension, but closed for modification". [[Luca Cardelli]] has stated that OOP languages have "extremely poor modularity properties with respect to class extension and modification", and tend to be extremely complex.<ref name="badprop"/> The latter point is reiterated by [[Joe Armstrong (programmer)|Joe Armstrong]], the principal inventor of [[Erlang (programming language)|Erlang]], who is quoted as saying:<ref name="armstrongjoe">{{cite book |last1=Armstrong |first1=Joe |author1-link=Joe Armstrong (programmer) |editor1-last=Seibel |editor1-first=Peter |title=Coders at Work: Reflections on the Craft of Programming |url=http://www.codersatwork.com/ |publisher=Codersatwork.com |archive-url=https://web.archive.org/web/20100305165150/http://www.codersatwork.com/ |archive-date=5 March 2010 |access-date=13 November 2009}}</ref>

{{Blockquote|The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.}}

Leo Brodie says that information hiding can lead to [[duplicate code]],<ref>{{Cite book |last1=Brodie |first1=Leo |year=1984 |url=https://thinking-forth.sourceforge.net/thinking-forth-ans.pdf |title=Thinking Forth |pages=92–93 |access-date=4 May 2018}}</ref> which goes against the [[don't repeat yourself]] rule of software development.<ref>{{cite web |work=Category Extreme Programming |last1=Hunt |first1=Andrew |url=http://wiki.c2.com/?DontRepeatYourself |title=Don't Repeat Yourself |access-date=4 May 2018}}</ref>

===Composition===

Via [[object composition]], an object can contain other objects. For example, an {{code|Employee}} object might contain an {{code|Address}} object, along with other information like {{code|name}} and {{code|position}}. Composition is a "has-a" relationships, like "an employee has an address".

===Inheritance===

[[Inheritance (object-oriented programming)|Inheritance]] be supported via the [[Class (computer programming)|class]] or the [[Prototype-based programming |prototype]], which have differences but use similar terms like object and [[instance (computer science)|instance]].

====Class-based====

In [[class-based programming]], the most common type of OOP, an object is an instance of a class. The class defines the data (variables) and methods (logic). An object is created via the [[Constructor (object-oriented programming)|constructor]]. Elements of class may include:

* [[Class variable]] – belongs to the class itself; all objects of the class share one copy

* [[Instance variable]] – belongs to an object; every object has its own version of these variables

* [[Member variable]] – refers to both the class and instance variables of a class

* Class method – can only use class variables

* Instance method – belongs to an objects; can use both instance and class variables

Classes may inherit from other classes, creating a hierarchy of classes: a case of a subclass inheriting from a super-class. For example, an {{code|Employee}} class might inherit from a {{code|Person}} class which endows the Employee object with the variables from {{code|Person}}. The subclass may add variables and methods that do not affect the super-class. Most languages also allow the subclass to override super-class methods. Some languages support [[multiple inheritance]], where a class can inherit from more than one class, and other languages similarly support [[mixin]]s or [[Trait (computer programming)|traits]]. For example, a mixin called UnicodeConversionMixin might add a method unicode_to_ascii() to both a FileReader and a WebPageScraper class.

An [[abstract class]] cannot be directly instantiated as an object. It is only used as a super-class.

Other classes are utility classes which contain only class variables and methods and are not meant to be instantiated or subclassed.{{sfn|Bloch|2018|loc=Chapter §2 Item 4 Enforce noninstantiability with a private constructor|p=19}}

====Prototype-based====

Instead of providing a class concept, in [[prototype-based programming]], an object is linked to another object, called its ''prototype'' or ''parent''. In Self, an object may have multiple or no parents,<ref>{{cite book |chapter=Classifying prototype-based programming languages|chapter-url=https://www.lirmm.fr/~dony/postscript/proto-book.pdf|first1=C|last1=Dony|first2=J|last2=Malenfant|first3=D|last3=Bardon|title=Prototype-based programming: concepts, languages and applications |date=1999 |publisher=Springer |___location=Singapore Berlin Heidelberg |isbn=9789814021258}}</ref> but in the most popular prototype-based language, [[JavaScript]], an object has exactly one prototype link, up to the base object whose prototype is null.

A prototype acts as a model for new objects. For example, if you have an object {{code|fruit}}, you can make two objects {{code|apple}} and {{code|orange}} that share traits of the {{code|fruit}} prototype. Prototype-based languages also allow objects to have their own unique properties, so the {{code|apple}} object might have an attribute {{code|sugar_content}}, while the {{code|orange}} or {{code|fruit}} objects do not.

====No inheritance====

Some languages, like [[Go (programming language)|Go]], don't support inheritance.<ref>{{Cite web |url=https://golang.org/doc/faq#Is_Go_an_object-oriented_language |title=Is Go an object-oriented language? |access-date=April 13, 2019 |quote=Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy.}}</ref> Instead, they encourage "[[composition over inheritance]]", where objects are built using smaller parts instead of parent-child relationships. For example, instead of inheriting from class Person, the Employee class could simply contain a Person object. This lets the Employee class control how much of Person it exposes to other parts of the program. [[Delegation (object-oriented programming)|Delegation]] is another language feature that can be used as an alternative to inheritance.

Programmers have different opinions on inheritance. Bjarne Stroustrup, author of C++, has stated that it is possible to do OOP without inheritance.<ref>{{cite conference |last1=Stroustrup |first1=Bjarne |author1-link=Bjarne Stroustrup |title=Object-Oriented Programming without Inheritance (Invited Talk) |date=2015 |doi=10.4230/LIPIcs.ECOOP.2015.1 |doi-access=free |url=https://www.youtube.com/watch?v=xcpSLRpOMJM |conference=29th European Conference on Object-Oriented Programming (ECOOP 2015) |at=1:34}}</ref> [[Rob Pike]] has criticized inheritance for creating complex hierarchies instead of simpler solutions.<ref>{{cite web |url=http://plus.google.com/+RobPikeTheHuman/posts/hoJdanihKwb |title=A few years ago I saw this page |last1=Pike |first1=Rob |access-date=1 October 2016 |date=14 November 2012|archive-url=https://web.archive.org/web/20180814173134/http://plus.google.com/+RobPikeTheHuman/posts/hoJdanihKwb |archive-date=14 August 2018}}</ref>

====Inheritance and behavioral subtyping====

People often think that if one class inherits from another, it means the subclass "[[is a]]" more specific version of the original class. This presumes the [[program semantics]] are that objects from the subclass can always replace objects from the original class without problems. This concept is known as [[behavioral subtyping]], more specifically the [[Liskov substitution principle]].

However, this is often not true, especially in programming languages that allow [[mutable]] objects, objects that change after they are created. In fact, [[subtype polymorphism]] as enforced by the [[type checker]] in OOP languages cannot guarantee behavioral subtyping in most if not all contexts. For example, the [[circle-ellipse problem]] is notoriously difficult to handle using OOP's concept of inheritance. Behavioral subtyping is undecidable in general, so it cannot be easily implemented by a compiler. Because of this, programmers must carefully design class hierarchies to avoid mistakes that the programming language itself cannot catch.

===Dynamic dispatch===

A method may be invoked via [[dynamic dispatch]] such that the method is selected at runtime instead of compile time. If the method choice depends on more than one type of object (such as other objects passed as parameters), it's called [[multiple dispatch]].

Dynamic dispatch works together with inheritance: if an object doesn't have the requested method, it looks up to its parent class ([[Delegation (object-oriented programming)|delegation]]), and continues up the chain to find a matching method.

===Message passing===

[[Message passing]] is when the method name and its inputs are sent like a message to the object for it to act on.

===Polymorphism===

[[Polymorphism (computer science)|Polymorphism]] refers to [[subtyping]] or subtype polymorphism, where a function can work with a specific [[Interface (object-oriented programming)|interface]] and thus manipulate entities of different classes in a uniform manner.<ref>{{cite web |url=http://www.stroustrup.com/glossary.html#Gpolymorphism |last1=Stroustrup |first1=Bjarne |author1-link=Bjarne Stroustrup |title=Bjarne Stroustrup's C++ Glossary |date=February 19, 2007 |quote=polymorphism – providing a single interface to entities of different types.}}</ref>

For example, imagine a program has two shapes: a circle and a square. Both come from a common class called "Shape." Each shape has its own way of drawing itself. With subtype polymorphism, the program doesn't need to know the type of each shape, and can simply call the "Draw" method for each shape. The programming language runtime will ensure the correct version of the "Draw" method runs for each shape. Because the details of each shape are handled inside their own classes, this makes the code simpler and more organized, enabling strong [[separation of concerns]].

===Open recursion===

An object's methods can access the object's data. Many programming languages use a special word, like [[this (computer programming)|{{code|this|C++}}]] or {{code|self|swift}}, to refer to the current object. In languages that support [[open recursion]], a method in an object can call other methods in the same object, including itself, using this special word. This allows a method in one class to call another method defined later in a subclass, a feature known as [[late binding]].

==Design patterns==

[[Design pattern (computer science)|Design patterns]] are common solutions to problems in software design. Some design patterns are especially useful for OOP, and design patterns are typically introduced in an OOP context.

===Object patterns===

The following are notable [[software design pattern]]s for OOP objects.<ref name="R.C.Martin">{{cite web |url=http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf |title=Design Principles and Design Patterns |last1=Martin |first1=Robert C. |author-link=Robert Cecil Martin |access-date=28 April 2017 |url-status=dead |archive-url=https://web.archive.org/web/20150906155800/http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf |archive-date=September 6, 2015}}</ref>

*[[Function object]]: Class with one main method that acts like an [[anonymous function]] (in C++, the function operator, {{code|operator()}})

*[[Immutable object]]: does not change state after creation

*[[First-class object]]: can be used without restriction

*[[Container object]]: contains other objects

*[[Factory object]]: creates other objects

*[[Metaobject]]: Used to create other objects (similar to a [[class (computer science)|class]], but an object)

*[[Prototype pattern|Prototype object]]: a specialized metaobject that creates new objects by copying itself

*[[Singleton pattern|Singleton object]]: only instance of its class for the lifetime of the program

*[[Filter object]]: receives a stream of data as its input and transforms it into the object's output

A common [[anti-pattern]] is the [[God object]], an object that knows or does too much.

===Gang of Four design patterns===

{{Main|Design Patternspattern (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.

''[[Design Patterns: Elements of Reusable Object-Oriented Software]]'' is a famous book published in 1994 by four authors: [[Erich Gamma]], [[Richard Helm]], [[Ralph Johnson (computer scientist)|Ralph Johnson]], and [[John Vlissides]]. People often call them the "Gang of Four". The book talks about the strengths and weaknesses of OOP and explains 23 common ways to solve programming problems.

As of April 2007, the book was in its 36th printing.

Typical design patterns are as follows:

These solutions, called "design patterns," are grouped into three types:

<div style="-moz-column-count:2; column-count:2;">

'''[[Creational pattern]]s'''

* ''[[Creational pattern]]s'' (5): [[Factory method pattern]], [[Abstract factory pattern]], [[Singleton pattern]], [[Builder pattern]], [[Prototype pattern]]

* [[Factory Pattern]]

* ''[[Structural pattern]]s'' (7): [[Adapter pattern]], [[Bridge pattern]], [[Composite pattern]], [[Decorator pattern]], [[Facade pattern]], [[Flyweight pattern]], [[Proxy pattern]]

* [[Abstract Factory Pattern]]

* ''[[Behavioral pattern]]s'' (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]]

* [[Singleton pattern|Singleton Pattern]]

* [[Builder pattern|Builder Pattern]]

* [[Prototype pattern|Prototype Pattern]]

'''[[Structural pattern]]s'''

* [[Adapter Pattern]]

* [[Bridge Pattern]]

* [[Composite Pattern]]

* [[Decorator Pattern]]

* [[Facade Pattern]]

* [[Flyweight Pattern]]

* [[Proxy pattern|Proxy Pattern]]

'''[[Behavioral pattern]]s'''

* [[Chain-of-responsibility pattern|Chain of Responsibility Pattern]]

* [[Command Pattern]]

* [[Interpreter Pattern]]

* [[Iterator Pattern]]

* [[Mediator Pattern]]

* [[Memento Pattern]]

* [[Observer Pattern]]

* [[State pattern]]

* [[Strategy Pattern]]

* [[Template Pattern]]

* [[Visitor Pattern]]

</div>

===Object-orientation and databases===

{{Main|Object-Relationalrelational impedance mismatch|Object-relational mapping|Object database}}

Both object-oriented programming and [[relational database management systems]] (RDBMSs) are extremely common in software {{As of|2006|alt=today}}. Since [[relational database]]s 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. There are a number of widely used solutions to this problem. One of the most common is [[object-relational mapping]], as found in libraries like [[Java Data Objects]] and [[Ruby on Rails]]' ActiveRecord.

Both OOP and [[relational database management systems]] (RDBMSs) are widely used in software today. However, [[relational database]]s don't store objects directly, which creates a challenge when using them together. This issue is called [[object-relational impedance mismatch]].

There are also [[object database]]s which can be used to replace RDBMSs, but these have not been as commercially successful as RDBMSs.

To solve this problem, developers use different methods, but none of them are perfect.<ref name="RDMDBobjectmis">{{Cite web |last1=Neward |first1=Ted |date=26 June 2006 |title=The Vietnam of Computer Science |access-date=2 June 2010 |publisher=Interoperability Happens |url=http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx |archive-url=https://web.archive.org/web/20060704030226/http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx |archive-date=4 July 2006 |url-status=dead |df=dmy-all}}</ref> One of the most common solutions is [[object-relational mapping]] (ORM), which helps connect object-oriented programs to relational databases. Examples of ORM tools include [[Visual FoxPro]], [[Java Data Objects]], and [[Ruby on Rails]] ActiveRecord.

===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]] programming language. However, not everyone agrees that direct real-world mapping is facilitated by OOP, or is even a worthy goal; [[Bertrand Meyer]] argues in [[Object-Oriented Software Construction]] <ref name="Meyer230">Meyer, Second Edition, p. 230</ref> 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. <ref>M.Trofimov, ''OOOP - The Third "O" Solution: Open OOP.'' First Class, [[Object Management Group|OMG]], 1993, Vol. 3, issue 3, p.14.</ref>

Some databases, called [[object database]]s, are designed to work with OOP. However, they have not been as popular or successful as relational databases.

However, Niklaus Wirth 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."

Date and Darwen have proposed a theoretical foundation that uses OOP as a kind of customizable [[data type|type system]] to support RDBMSs, but it forbids objects containing pointers to other objects.<ref name="ThirdManifesto">C. J. Date, Hugh Darwen. ''Foundation for Future Database Systems: The Third Manifesto'' (2nd Edition)</ref>

==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:

===Responsibility- vs. data-driven design===

* [[F-Coalgebra|coalgebraic datatypes]]

In [[responsibility-driven design]], classes are built around what they need to do and the information they share, in the form of a contract. This is different from [[Data-driven programming|data-driven design]], where classes are built based on the data they need to store. According to Wirfs-Brock and Wilkerson, the originators of responsibility-driven design, responsibility-driven design is the better approach.<ref name="Wirfs-Brock1989">{{cite journal|last1=Wirfs-Brock|first1=Rebecca|last2=Wilkerson|first2=Brian|title=Object-Oriented Design: A Responsibility-Driven Approach|journal=ACM SIGPLAN Notices|date=1989|volume=24|issue=10|page=74|doi=10.1145/74878.74885|doi-access=free}}</ref>

* [[existential quantification]] and [[Module (programming)|modules]]

* [[recursion]]

* [[Record (computer science)|records]] and [[record extension]]s

* [[F-bounded polymorphism]]

===SOLID and GRASP guidelines===

Attempts to find a consensus definition or theory behind objects have not proven very successful (however, see "Abadi & Cardelli: A Theory of Objects" <ref name="AbadiCardelli">''[http://portal.acm.org/citation.cfm?id=547964&dl=ACM&coll=portal A Theory of Objects]'', Martin Abadi and Luca Cardelli</ref> 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").

[[SOLID]] is a set of five rules for designing good software, created by Michael Feathers:

* [[Single responsibility principle]]: A class should have only one reason to change.

===OOPS===

* [[Open/closed principle]]: Software entities should be open for extension, but closed for modification.

The term OOPS, which refers to an '''o'''bject-'''o'''riented '''p'''rogramming '''s'''ystem, is widely used and was common in early development of object-oriented programming.{{Fact|date=January 2009}}

* [[Liskov substitution principle]]: Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

* [[Interface segregation principle]]: Clients should not be forced to depend upon interfaces that they do not use.

* [[Dependency inversion principle]]: Depend upon abstractions, not concretes.

[[GRASP (object-oriented design)|GRASP]] (General Responsibility Assignment Software Patterns) is another set of software design rules, created by [[Craig Larman]], that helps developers assign responsibilities to different parts of a program:<ref>{{Cite web |last1=Karsh |first1=Patrick |date=Jul 19, 2023 |title=GRASP Principles: Object-Oriented Design Patterns |url=https://patrickkarsh.medium.com/object-oriented-design-with-grasp-principles-8049fa63e52 |access-date=Mar 30, 2025 |website=Medium}}</ref>

== Criticism ==

* Creator Principle: allows classes create objects they closely use.

* [[Luca Cardelli]] wrote a paper titled '[http://doc.cat-v.org/programming/bad_properties_of_OO Bad Engineering Properties of Object-Oriented Languages]'.

* Information Expert Principle: assigns tasks to classes with the needed information.

* [[Richard Stallman]] wrote in 1995, "Adding OOP to [[Emacs]] is not clearly an improvement; I used OOP when working on the [[Lisp Machine]] [[window system]]s, and I disagree with the usual view that it is a superior way to program."<ref>{{cite web|url=http://groups.google.com/group/comp.emacs.xemacs/browse_thread/thread/d0af257a2837640c/37f251537fafbb03?lnk=st&q=%22Richard+Stallman%22+oop&rnum=5&hl=en#37f251537fafbb03|title=Mode inheritance, cloning, hooks & OOP (Google Groups Discussion)}}</ref>

* Low Coupling Principle: reduces class dependencies to improve flexibility and maintainability.

* A study by Potok et al. <ref>http://www.csm.ornl.gov/~v8q/Homepage/Papers%20Old/spetep-%20printable.pdf</ref> has shown no significant difference in productivity between OOP and procedural approaches.

* High Cohesion Principle: designing classes with a single, focused responsibility.

* [[Christopher J. Date]] stated that critical comparison of OOP to other technologies, relational in particular, is difficult because of lack of an agreed-upon and rigorous definition of OOP.<ref name="DatePage650">C. J. Date, Introduction to Database Systems, 6th-ed., Page 650</ref>

* Controller Principle: assigns system operations to separate classes that manage flow and interactions.

* [[Alexander Stepanov]] suggested that OOP provides a mathematically-limited viewpoint and called it, "almost as much of a hoax as Artificial Intelligence" (possibly referring to the [[Artificial Intelligence]] projects and marketing of the 1980s that are sometimes viewed as overzealous in retrospect)<ref>[http://www.aaai.org/aitopics/html/aieffect.html The AI Effect<!-- Bot generated title -->]</ref><ref>[http://www.stlport.org/resources/StepanovUSA.html STLport: An Interview with A. Stepanov<!-- Bot generated title -->]</ref>.

* Polymorphism: allows different classes to be used through a common interface, promoting flexibility and reuse.

* Pure Fabrication Principle: create helper classes to improve design, boost cohesion, and reduce coupling.

==Formal semantics==

Researchers have tried to formally define the [[Semantics (computer science)|semantics]] of OOP. [[Inheritance (object-oriented programming)|Inheritance]] presents difficulties, particularly with the interactions between open recursion and encapsulated state. Researchers have used [[recursive type]]s and [[F-Coalgebra|co-algebraic data types]] to incorporate essential features of OOP.<ref name=poll97>{{cite web|last1=Poll|first1=Erik|title=Subtyping and Inheritance for Categorical Datatypes|url=https://www.cs.ru.nl/E.Poll/papers/kyoto97.pdf|access-date=5 June 2011}}</ref> Abadi and Cardelli defined several extensions of [[System F-sub|System F_<:]] that deal with mutable objects, allowing both [[subtype polymorphism]] and [[parametric polymorphism]] (generics), and were able to formally model many OOP concepts and constructs.<ref name="AbadiCardelli">{{Cite book |first1=Martin |last1=Abadi |title=A Theory of Objects |url=http://portal.acm.org/citation.cfm?id=547964&dl=ACM&coll=portal |year=1996 |access-date=21 April 2010 |isbn=978-0-387-94775-4 |publisher=Springer-Verlag New York, Inc. |author-link=Martin Abadi|author2=Cardelli, Luca}}</ref> Although far from trivial, static analysis of object-oriented programming languages such as Java is a mature field,<ref>{{cite conference |last1=Tan |first1=Tian |last2=Li |first2=Yue |date=12 July 2023 |title=Tai-e: A Developer-Friendly Static Analysis Framework for Java by Harnessing the Good Designs of Classics|conference=ISSTA 2023 |pages=1093–1105 |doi=10.1145/3597926.3598120}}</ref> with several commercial tools.<ref>{{cite journal |last1=Bhutani |first1=Vikram |last2=Toosi |first2=Farshad Ghassemi |last3=Buckley |first3=Jim |date=1 June 2024 |title=Analysing the Analysers: An Investigation of Source Code Analysis Tools |journal=Applied Computer Systems |volume=29 |issue=1 |pages=98–111 |doi=10.2478/acss-2024-0013}}</ref>

=={{anchor|Criticism}}Criticism==

Some believe that OOP places too much focus on using objects rather than on [[algorithm]]s and [[data structure]]s.<ref name="stepanov"/><ref name="hickey"/> For example, programmer [[Rob Pike]] pointed out that OOP can make programmers think more about type hierarchy than composition.<ref name="RobPike">{{cite web |url=https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html |title=Less is exponentially more |last1=Pike |first1=Rob |date=25 June 2012 |access-date=1 October 2016}}</ref> He has called OOP "the [[Roman numerals]] of computing".<ref>{{cite mailing list |last1=Pike |first1=Rob |author1-link=Rob Pike |date=2 March 2004 |url=http://groups.google.com/group/comp.os.plan9/msg/006fec195aeeff15 |title=[9fans] Re: Threads: Sewing badges of honor onto a Kernel |access-date=17 November 2016 |mailing-list=comp.os.plan9}}</ref> [[Rich Hickey]], creator of [[Clojure]], described OOP as overly simplistic, especially when it comes to representing real-world things that change over time.<ref name="hickey">{{cite conference |last1=Hickey |first1=Rich |date=November 2009 |url=http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey |title=Are We There Yet? (keynote) |conference=JVM Languages Summit}}</ref> [[Alexander Stepanov]] said that OOP tries to fit everything into a single type, which can be limiting. He argued that sometimes we need multisorted algebras: families of interfaces that span multiple types, such as in [[generic programming]]. Stepanov also said that calling everything an "object" doesn't add much understanding.<ref name="stepanov">{{Cite web |last1=Stepanov |first1=Alexander |author1-link=Alexander Stepanov |year=2001–2008 |url=http://www.stlport.org/resources/StepanovUSA.html |title=STLport: An Interview with A. Stepanov |access-date=21 April 2010}}</ref>

OOP was created to make code easier to [[code reuse|reuse]] and [[software maintenance|maintain]].<ref name="realisticcodereuse">{{Cite web |last1=Ambler |first1=Scott |date=1 January 1998 |title=A Realistic Look at Object-Oriented Reuse |access-date=5 August 2025 |publisher=drdobbs.com |url=http://www.drdobbs.com/184415594}}</ref> However, it was not designed to clearly show the flow of a program's instructions. That was left to the compiler. As computers began using more parallel processing and multiple [[thread (computer science)|threads]], it became more important to understand and control how instructions flow. This is difficult to do with OOP.<ref name="flaws">{{Cite web |first1=Asaf |last1=Shelly |title=Flaws of Object Oriented Modeling |date=22 August 2008|access-date=4 July 2010 |publisher=Intel Software Network |url=http://software.intel.com/en-us/blogs/2008/08/22/flaws-of-object-oriented-modeling/}}</ref><ref name="multithreadingisaverb">{{Cite web |first1=Justin |last1=James |title=Multithreading is a verb not a noun |date=1 October 2007 |access-date=4 July 2010 |publisher=techrepublic.com |url=http://blogs.techrepublic.com.com/programming-and-development/?p=518 |archive-url=https://web.archive.org/web/20071010105117/http://blogs.techrepublic.com.com/programming-and-development/?p=518 |archive-date=10 October 2007 |url-status=dead |df=dmy-all}}</ref><ref name="multicore">{{Cite web |first1=Asaf |last1=Shelly |title=HOW TO: Multicore Programming (Multiprocessing) Visual C++ Class Design Guidelines, Member Functions |date=22 August 2008 |access-date=4 July 2010 |publisher=support.microsoft.com |url=http://support.microsoft.com/?scid=kb%3Ben-us%3B558117}}</ref><ref>{{cite web|url=http://existentialtype.wordpress.com/2011/04/17/some-advice-on-teaching-fp/|title=Some thoughts on teaching FP|author=Robert Harper |publisher=Existential Type Blog|access-date=5 December 2011|date=17 April 2011|author-link=Robert Harper (computer scientist)}}</ref>

Many popular programming languages, like C++, Java, and Python, use OOP. In the past, OOP was widely accepted,<ref>{{cite book |last1=Brucker |first1=Achim D. |last2=Wolff |first2=Burkhart |title=ECOOP 2008 – Object-Oriented Programming |chapter=Extensible Universes for Object-Oriented Data Models |series=Lecture Notes in Computer Science |date=2008 |volume=5142 |pages=438–462 |doi=10.1007/978-3-540-70592-5_19|isbn=978-3-540-70591-8 |quote=object-oriented programming is a widely accepted programming paradigm}}</ref> but recently, some programmers have criticized it and prefer functional programming instead.<ref>{{cite news |last1=Cassel |first1=David |title=Why Are So Many Developers Hating on Object-Oriented Programming? |url=https://thenewstack.io/why-are-so-many-developers-hating-on-object-oriented-programming/ |work=The New Stack |date=21 August 2019}}</ref> A study by Potok et al. found no major difference in productivity between OOP and other methods.<ref>{{Cite journal |url=http://www.csm.ornl.gov/~v8q/Homepage/Papers%20Old/spetep-%20printable.pdf |title=Productivity Analysis of Object-Oriented Software Developed in a Commercial Environment |last1=Potok |first1=Thomas |last2=Vouk |first2=Mladen |last3=Rindos |first3=Andy |journal=Software: Practice and Experience |volume=29|issue=10|pages=833–847 |year=1999 |access-date=21 April 2010 |doi=10.1002/(SICI)1097-024X(199908)29:10<833::AID-SPE258>3.0.CO;2-P |s2cid=57865731}}</ref>

[[Paul Graham (computer programmer)|Paul Graham]], a well-known computer scientist, believes big companies like OOP because it helps manage large teams of average programmers. He argues that OOP adds structure, making it harder for one person to make serious mistakes, but at the same time restrains smart programmers.<ref name="graham">{{Cite web |last1=Graham |first1=Paul |title=Why ARC isn't especially Object-Oriented. |url=http://www.paulgraham.com/noop.html |publisher=PaulGraham.com |access-date=13 November 2009 |author-link=Paul Graham (computer programmer)}}</ref> [[Eric S. Raymond]], a [[Unix]] programmer and [[open-source software]] advocate, argues that OOP is not the best way to write programs.<ref name="Eric S. Raymond 2003"/>

Richard Feldman says that, while OOP features helped some languages stay organized, their popularity comes from other reasons.<ref>{{cite web |last1=Feldman |first1=Richard |title=Why Isn't Functional Programming the Norm? |website=[[YouTube]] |date=30 September 2019 |url=https://www.youtube.com/watch?v=QyJZzq0v7Z4&t=2069s |language=en}}</ref> Lawrence Krubner argues that OOP doesn't offer special advantages compared to other styles, like functional programming, and can complicate coding.<ref name="lawrence">{{Cite web |last1=Krubner |first1=Lawrence |title=Object Oriented Programming is an expensive disaster which must end |url=http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end |publisher=smashcompany.com |access-date=14 October 2014 |archive-url=https://web.archive.org/web/20141014233854/http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end |archive-date=14 October 2014 |url-status=dead}}</ref> [[Luca Cardelli]] says that OOP is slower and takes longer to compile than procedural programming.<ref name="badprop">{{Cite journal |first1=Luca |last1=Cardelli|title=Bad Engineering Properties of Object-Oriented Languages |url=http://lucacardelli.name/Papers/BadPropertiesOfOO.html |year=1996 |access-date=21 April 2010 |doi=10.1145/242224.242415 |journal=ACM Comput. Surv. |volume=28 |issn=0360-0300 |pages=150–es |author-link=Luca Cardelli |issue=4es |s2cid=12105785 |url-access=subscription}}</ref>

==See also==

{{Portal|Computer programming}}

<div style="-moz-column-count:3; column-count:3;">

* [[CADES]]

* [[Object-oriented programming language]]

* [[Common Object Request Broker Architecture]] (CORBA)

* [[Aspect-oriented programming]]

* [[ProceduralComparison of programming languages (object-oriented programming)]]

* [[Component-based software engineering]]

* [[Object-oriented analysis and design]]

* [[Distributed Component Object Model]]

* [[Circle-ellipse problem]]

* [[Software componentry]]

* [[Interface description language]]

* [[Dot notationIDEF4]]

* [[Jeroo]]
* [[List of object-oriented programming termslanguages]]

* [[Refactoring]]

* [[CORBA]]

* [[Distributed Component Object Model|DCOM]]

* [[Object association]]

* [[Object-relationaloriented mappinganalysis and design]]

* [[Object-oriented modeling]]

* [[Object-relational impedance mismatch]] (and [[The Third Manifesto]])

* [[Object-oriented databaseontology]]

* [[Constructor overloadingUML]]

* [[Lepus3]] an Object-Oriented design description language

* [[Abstract data type]]

* [[Design by contract]]

</div>

==References==

{{reflistReflist}}

==Further reading==

* {{Cite book

|first1=Martin

{{wikibookspar|Computer programming|Object oriented programming}}

|last1=Abadi

{{wikiversity2|Topic:Object-Oriented Programming}}

|author-link=Martin Abadi

* {{cite book

|author2=Luca Cardelli

|first=Stephen

|year=1998

|last=Schach

|authorlink=Stephen R Schach

|year=2006

|title=Object-Oriented and Classical Software Engineering, Seventh Edition

|publisher=McGraw-Hill

|isbn=0-073-19126-4

}}

* {{cite book

|first=Martin

|last=Abadi

|authorlink=Martin Abadi

|coauthors=[[Luca Cardelli]]

|year=

|title=A Theory of Objects

|publisher=[[Springer- Verlag]]

|isbn=978-0-387-94775-24

|author2-link=Luca Cardelli

}}

* {{citeCite book

|firstfirst1=Harold

|lastlast1=Abelson

|authorlinkauthor-link=Harold Abelson

|coauthorsauthor2=[[Gerald Jay Sussman]],

|year=1997

|title=[http://mitpress.mit.edu/sicp/ Structure and Interpretation of Computer Programs]

|url=http://mitpress.mit.edu/sicp/

|publisher=The MIT Press

|publisher=[[MIT Press]]

|isbn=0-262-01153-0

|isbn=978-0-262-01153-2

|author2-link=Gerald Jay Sussman

|access-date=22 January 2006

|archive-date=26 December 2017

|archive-url=https://web.archive.org/web/20171226134539/http://mitpress.mit.edu/sicp/

|url-status=dead

}}

* {{citeCite journal

|first1=Deborah J.

| last = Armstrong

|last1=Armstrong

| first = Deborah J.

| year date=February 2006

|title=The Quarks of Object-Oriented Development

| month = February

|journal=Communications of the ACM

| title = The Quarks of Object-Oriented Development

|volume=49

| journal = Communications of the ACM

|issue=2

| volume = 49

|pages=123–128

| issue = 2

|issn=0001-0782

| pages = 123–128

|doi=10.1145/1113034.1113040

| id = {{ISSN|0001-0782}}

|s2cid=11485502

| url =http://portal.acm.org/citation.cfm?id=1113040

}}

| accessdate = 2006-08-08

*{{cite book

| doi = 10.1145/1113034.1113040

|title="Effective Java: Programming Language Guide"

}}

|last1=Bloch

* {{cite book

|first1=Joshua

|first=Grady

|publisher=Addison-Wesley

|last=Booch

|edition=third

|authorlink=Grady Booch

|isbn=978-0134685991

|year=

|year=2018

}}

* {{Cite book

|last1=Booch

|first1=Grady

|author1-link=Grady Booch

|year=1997

|title=Object-Oriented Analysis and Design with Applications

|publisher=[[Addison-Wesley]]

|isbn=978-0-8053-5340-2

|url=https://archive.org/details/objectorientedan00booc

}}

* {{citeCite book

|firstfirst1=Peter

|lastlast1=Eeles

|author2=Oliver Sims

|authorlink=Peter Eeles

|year=1998

|coauthors=[[Oliver Sims]]

|year=

|title=Building Business Objects

|publisher=[[John Wiley & Sons]]

|isbn=978-0-471-19176-06

|url=https://archive.org/details/buildingbusiness0000eele

|author2-link=Oliver Sims

}}

* {{citeCite book

|firstfirst1=Erich

|lastlast1=Gamma

|authorlinkauthor-link=Erich Gamma

|coauthorsauthor2=[[Richard Helm]], [[Ralph Johnson]], [[John Vlissides]]

|author3-link=Ralph Johnson (computer scientist)

|year=

|author3=Ralph Johnson

|author4-link=John Vlissides

|author4=John Vlissides

|year=1995

|title=Design Patterns: Elements of Reusable Object Oriented Software

|publisher=Addison-Wesley

|isbn=978-0-201-63361-20

|bibcode=1995dper.book.....G

|url=https://archive.org/details/designpatternsel00gamm

|author2-link=Richard Helm

}}

* {{citeCite book

|firstfirst1=Paul

|lastlast1=Harmon

|authorlinkauthor-link=Paul Harmon (management author)

|coauthorsauthor2=[[William Morrissey]]

|year=1996

|title=The Object Technology Casebook -– Lessons from Award-Winning Business Applications

|publisher=John Wiley & Sons

|isbn=978-0-471-14717-6

|url=https://archive.org/details/objecttechnology00harm

}}

* {{citeCite book

|firstfirst1=Ivar

|lastlast1=Jacobson

|authorlinkauthor-link=Ivar Jacobson

|year=1992

|title=Object-Oriented Software Engineering: A [[use case|Use Case]]-Driven Approach

|publisher=Addison-Wesley

|isbn=978-0-201-54435-0

|title-link=Use case

|bibcode=1992oose.book.....J

}}

* {{citeCite book

|firstfirst1=Alan

|lastlast1=Kay

|authorlinkauthor-link=Alan Kay

|title=The Early History of Smalltalk

|year=

|url=http://gagne.homedns.org/%7etgagne/contrib/EarlyHistoryST.html

|title=The Early History of Smalltalk

|access-date=18 April 2005

|url=http://gagne.homedns.org/%7etgagne/contrib/EarlyHistoryST.html

|archive-url=https://web.archive.org/web/20050404075821/http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html

|archive-date=4 April 2005

|url-status=dead

|df=dmy-all

}}

* {{citeCite book

|firstfirst1=Bertrand

|lastlast1=Meyer

|authorlinkauthor-link=Bertrand Meyer

|year=1997

|title=[[Object-Oriented Software Construction]]

|publisher=[[Prentice Hall]]

|isbn=978-0-13-629155-48

|url=https://bertrandmeyer.com/OOSC2/

|url=

}}

* {{Cite book

|first1=Rudolf

|last1=Pecinovsky

|year=2013

|title=OOP – Learn Object Oriented Thinking & Programming

|publisher=Bruckner Publishing

|isbn=978-80-904661-8-0

|url=http://pub.bruckner.cz/titles/oop

}}

* {{citeCite book

|last1=Rumbaugh

|first=James

|first1=James

|last=Rumbaugh

|authorlinkauthor1-link=James Rumbaugh

|last2=Blaha |first2=Michael

|coauthors=[[Michael Blaha]], [[William Premerlani]], [[Frederick Eddy]], [[William Lorensen]]

|last3=Premerlani |first3=William

|year=

|last4=Eddy |first4=Frederick

|last5=Lorensen |first5=William

|year=1991

|title=Object-Oriented Modeling and Design

|publisher=Prentice Hall

|isbn=978-0-13-629841-90

|url=https://archive.org/details/objectorientedmo00rumb

}}

* {{citeCite book

|first1=Stephen

|first=David A.

|last1=Schach

|last=Taylor

|year=2006

|authorlink=David A. Taylor

|title=Object-Oriented and Classical Software Engineering, Seventh Edition

|year=

|publisher=[[McGraw-Hill]]

|title=Object-Oriented Information Systems - Planning and Implementation

|isbn=978-0-07-319126-3

}}

* {{Cite book

|first1=Axel-Tobias

|last1=Schreiner

|year=1993

|title=Object oriented programming with ANSI-C

|publisher=Hanser

|isbn=978-3-446-17426-9

|hdl=1850/8544}}

* {{Cite book

|first1=David A.

|last1=Taylor

|year=1992

|title=Object-Oriented Information Systems – Planning and Implementation

|publisher=John Wiley & Sons

|isbn=978-0-471-54364-0

|url=https://archive.org/details/objectorientedin00tayl

}}

* {{Cite book

|first1=Matt

|last1=Weisfeld

|year=2009

|title=The Object-Oriented Thought Process, Third Edition

|publisher=[[Addison-Wesley]]

|isbn=978-0-672-33016-2

}}

* {{Cite book

|first1=David

|last1=West

|year=2004

|title=Object Thinking (Developer Reference)

|publisher=[[Microsoft Press]]

|isbn=978-0-7356-1965-4

}}

== External links ==

{{Wikiquote|Object-orientation}}

* [http://www.dreamincode.net/forums/blog/gabehabe/index.php?showentry=1016 Programming Styles: Procedural, OOP, and AOP]

{{Wikiversity|at=Topic:Object-Oriented Programming}}

{{Wikibooks|Object Oriented Programming}}

* [http://www.codeproject.com/Articles/22769/Introduction-to-Object-Oriented-Programming-Concep Introduction to Object Oriented Programming Concepts (OOP) and More] by L.W.C. Nirosh

*[https://thenewstack.io/why-are-so-many-developers-hating-on-object-oriented-programming/ Discussion on Cons of OOP]

* [http://java.sun.com/docs/books/tutorial/java/concepts/ OOP Concepts (Java Tutorials)]

{{Programming paradigms navbox}}

{{Software Engineering}}

{{Types of programming languages}}

{{Software engineering}}

{{Authority control}}

{{DEFAULTSORT:Object-Oriented Programming}}

[[Category:Object-oriented programming|*]]

[[Category:Object-oriented programming| ]]

[[Category:Programming paradigms]]

<!-- Hidden categories below -->

[[Category:Articles with example code]]

{{Link FA|vi}}

[[af:Objekgeoriënteerde programmering]]

[[ar:برمجة كائنية التوجه]]

[[bn:অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং]]

[[be-x-old:Аб'ектна-арыентаванае праграмаваньне]]

[[bs:Objektno orijentisano programiranje]]

[[bg:Обектно-ориентирано програмиране]]

[[ca:Programació orientada a objectes]]

[[cs:Objektově orientované programování]]

[[da:Objektorienteret programmering]]

[[de:Objektorientierte Programmierung]]

[[el:Αντικειμενοστρεφής προγραμματισμός]]

[[es:Programación orientada a objetos]]

[[eo:Objektema programado]]

[[eu:Objektuei orientatutako programazio]]

[[fa:برنامه‌نویسی شیءگرا]]

[[fr:Programmation orientée objet]]

[[gl:Programación orientada a obxectos]]

[[ko:객체 지향 프로그래밍]]

[[hr:Objektno orijentirano programiranje]]

[[io:Objektema programado]]

[[id:Pemrograman berorientasi objek]]

[[is:Hlutbundin forritun]]

[[it:Programmazione orientata agli oggetti]]

[[he:תכנות מונחה עצמים]]

[[ka:ობიექტზე ორიენტირებული პროგრამირება]]

[[lt:Objektinis programavimas]]

[[hu:Objektumorientált programozás]]

[[ms:Pengaturcaraan berorientasi objek]]

[[nl:Objectgeoriënteerd]]

[[ja:オブジェクト指向]]

[[no:Objektorientert programmering]]

[[pl:Programowanie obiektowe]]

[[pt:Orientação a objetos]]

[[ro:Programare orientată pe obiecte]]

[[ru:Объектно-ориентированное программирование]]

[[simple:Object-oriented programming]]

[[sk:Objektové programovanie]]

[[sr:Објектно-оријентисано програмирање]]

[[sh:Objektno orijentisano programiranje]]

[[fi:Olio-ohjelmointi]]

[[sv:Objektorienterad programmering]]

[[ta:பொருள் நோக்கு நிரலாக்கம்]]

[[th:การเขียนโปรแกรมเชิงวัตถุ]]

[[vi:Lập trình hướng đối tượng]]

[[tr:Nesne Yönelimli Programlama]]

[[uk:Об'єктно-орієнтоване програмування]]

[[wuu:面向对象程式编制]]

[[zh:面向对象程序设计]]