Object-oriented programming: Difference between revisions

Content deleted Content added
typo
 
Line 1:
{{short description|Programming paradigm based on objects}}
In [[computer science]], '''object-oriented programming''', '''OOP''' for short, is a computer [[programming paradigm]].
{{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]] based on the [[Object (computer science)|object]]<ref name=alanKayOnOO/> – a [[software]] entity that [[encapsulation (programming)|encapsulates]] [[data]] and [[Function (computer programming)|function(s)]]. An OOP [[computer program]] consists of objects that interact with one another.<ref>{{Cite journal
The idea behind object-oriented programming is that a computer program may be seen as comprising a collection of individual units, or ''objects'', that act on each other, as opposed to a traditional view in which a program may be seen as a collection of [[subroutine|functions]], or simply as a list of [[instructions]] to the computer. Each object is capable of receiving [[message (computer science)|messages]], processing data, and sending messages to other objects. Each object can be viewed as an independent little machine or actor with a distinct role or responsibility. [[Procedural to OOP]] may help understanding the concept using code.
|last1=Kindler |first1=E.
|last2=Krivy |first2=I.
|year=2011
|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
Object-oriented programming is claimed to promote greater flexibility and [[maintainability]] in programming, and is widely popular in large-scale [[software engineering]]. Furthermore, proponents of OOP claim that OOP is easier to learn for those new to [[computer programming]] than previous approaches, and that the OOP approach is often simpler to develop and to maintain, lending itself to more direct analysis, coding, and understanding of complex situations and procedures than other programming methods. Critics dispute this, at least for some domains (industries).
|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>
==Fundamental concepts==
Object-oriented programming (OOP) emphasizes the following concepts:
 
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]] 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)]].
*[[Class (computer science)|Class]] &mdash; the unit of definition of data and behavior (functionality) for some kind-of-thing. For example, the 'class of Dogs' might be a [[set]] which includes the various breeds of dogs. A class is the basis of [[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,'' and the code for a class should be (relatively) self-contained and independent (as should the code for any good non-OOP [[subroutine|function]]). With such modularity, the structure of a program will correspond to the [[aspect]]s of the [[problem]] that the program is intended to solve. This simplifies the [[Map (mathematics)|mapping]] to and from the problem and program.
 
==History==
*[[Object (computer science)|Object]] &mdash; an instance of a class, an object (for example, "Lassie" the Dog) is the run-time manifestation (''instantiation'') of a ''particular exemplar'' of a class. (For the class of dogs which contains breed types, an acceptable exemplar would only be the '''''subclass''''' 'collie'; "Lassie" would then be an object in that subclass.) Each object has its own data, though the code within a class (or a subclass or an object) may be shared for economy. <!-- This is more or less an implementation issue, inappropriate to an overview : "Thus, object-oriented languages must allow code to be [[reentrant]]" -->
 
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
* [[Method (computer science)|Method]] (also known as ''message'') &mdash; how code can use an object of some class. A ''method'' is a form of [[subroutine]] operating on a single object. Methods may be divided into '''queries''' returning the current state and '''commands''' changing it: a <code>Dog</code> could have a query <code>Age</code> to say how old it is, and command <code>chase (Rabbit target)</code> to start it chasing a rabbit. A method may also do both, but some authorities (e.g. [[Bertrand Meyer]]) recommend they be kept separate. Sometimes access to the data of an object is restricted to the methods of its class.
|last1=McCarthy
** A '''member''' of a class or object is a method or a data item describing the state of an object. In some languages the general term is '''feature'''.
|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>
* [[Inheritance (computer science)|Inheritance]] &mdash; a mechanism for creating subclasses, inheritance provides a way to define a (sub)class as a specialization or subtype or extension of a more general class: <code>Dog</code> is a subclass of <code>Canidae</code>, and <code>Collie</code> is a subclass of the (sub)class <code>Dog</code>. A subclass ''inherits'' all the members of its superclass(es), but it can extend their behaviour and add new members. Inheritance is the "is-a" relationship: a <code>Dog</code> ''is a'' <code>Canidae</code>. This is in contrast to [[Object composition|composition]], the "has-a" relationship<!-- Too much detail for this overviw: ", which user-defined datatypes brought to computer science" -->: a <code>Dog</code> ''has a'' mother (another <code>Dog</code>) and ''has a'' father, etc.
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>
** [[Multiple inheritance]] &ndash; a <code>Dog</code> is both a <code>Pet</code> and a <code>Canidae</code> &ndash; is not always supported, as it can be hard both to implement and to use well.
 
{{Quote box
* [[Information hiding|Encapsulation]] &mdash; ensuring that code outside a class sees only functional details of that class, but not implementation details. The latter are liable to change, and could allow a user to put an object in an inappropriate state. 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]]'' &mdash; those members accessible to that class. 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''' and '''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 '''protected''' keyword to restrict access also to classes in the same package, [[C sharp|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]] allows one to specify which classes may access any member.
|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).
|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>
*[[Abstraction (computer science)|Abstraction]] &mdash; the ability of a program to ignore the details of an object's (sub)class and work at a more generic level when appropriate; For example, "Lassie" the Dog may be treated as a Dog much of the time, but when appropriate she is abstracted to the level of Canidae (superclass of Dog) or Carnivora (superclass of Canidae), and so on.
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
*[[polymorphism (computer science)|Polymorphism]] &mdash; polymorphism is behavior that varies depending on the class in which the behavior is invoked, that is, two or more classes can react ''differently'' to the ''same message''. For example, if '''Dog''' is commanded to '''speak''' this may elicit a '''Bark'''; if '''Pig''' is commanded to '''speak''' this may elicit an '''Oink'''.
|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]].
An '''[[object-based language|object-''based'' language]]''' is a language that has most of the properties of an object-oriented language, but may lack some. For example [[Visual Basic]] lacks inheritance, while a [[Prototype-based programming]] language relies on prototypes instead of classes to create objects.
 
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}}
==Matching Real World==
 
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}}
According to some OOP proponents, translation from real-world phenomena/objects (and vice versa) is eased because of a direct [[mapping]] from the real-world to the object-oriented program (generally a [[many-to-one]]). OOP was even invented for the purpose of physical modelling in the [[Simula-67]] programming language. However, not all proponents agree that real-world mapping is facilitated by OOP, or is even a worthy goal ([[Bertrand Meyer]], OOSC2, pg. 230).
 
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.
==OOP as a new paradigm, point of view, and marketing term==
OOP is subject to much contention as to its precise definition and its principal ideas.
 
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]].
In the most general terms, OOP is the practice of writing program text that is decomposed into modules that encapsulate the representation of one data type per module, instead of into collections of functions that call each other, or clauses that trigger each other. OOP concepts and practices have been brought together, with associated terminology, to create a new programming framework. Together, the ideas behind OOP are said to be so powerful that they create a [[paradigm shift]] in programming. (Other programming paradigms, such as [[Functional programming|functional]] and [[procedural programming|procedural]] programming, focus primarily on [[Action (philosophy)|actions]] -- or, in [[logical programming|logical]] programming, on [[Assertion (computing)|assertions]] -- that trigger execution of program code.)
 
==Features==
OOP arose independently out of research into simulation system oriented languages, with SIMULA 67, and out of research into highly secure system architectures, with capability-based OS and CPU architectures.
{{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===
Some experts say that the original definition of object-orientation came from the [[object (grammar)|object]] in [[grammar]]. The requirements for software are always [[subject (grammar)| subject]]-oriented. However, since the requirements for the subject are often complicated, subject-oriented programs end up tending to be complicated and monolithic. Therefore, as an alternative, some researchers started thinking in an ''object''-oriented way. This represented a [[paradigm shift]] from the usual or previous ''subject''-oriented mode of thinking.
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===
According to object-oriented principles, the [[verb]] in a program statement is always attached to the object, and the logic associated with a requirement is likewise handled in the object. The following are some examples of the ways by which a subject-oriented requirement is translated into object-oriented thinking:
[[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.
 
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>
*'''Subject-oriented:''' The Sales Application saves the Transaction
*'''Object-oriented:''' The Transaction saves itself upon receiving a message from the Sales Application
 
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"/>
*'''Subject-oriented:''' The Sales Application prints the Receipt
*'''Object-oriented:''' The Receipt prints itself upon receiving a message from the Sales Application
 
[[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>
One distinguishing feature of OOP is the handling of [[subtype]]s of [[datatype|data type]]s.
 
{{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.}}
Objects' data are generally required to satisfy programmer-defined constraints (i.e., [[class (computer science)|class invariant]]s). A datatype restricted by such a constraint constitutes a subtype of the same datatype without the constraint. These constraints are then both relied upon and preserved by the actions (methods) that are defined for the data.
 
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>
Data constraints may be either explicitly declared or implicitly assumed by the programmer. In either case, object-oriented languages provide mechanisms for ensuring that such assumptions or constraints remain local to one part of the program. Constraints on and assumptions about data are usually included in the [[documentation]] of object-oriented programs.
 
===Composition===
OOP itself has been used to market many products and services, and the actual definitions and benefits attributed to OOP have often been colored by commercial marketing goals. Similarly, many [[programming language]]s reflect a specific view or philosophy of OOP that is narrower and, in certain respects, less general than that embodied in the more general or standard definition.
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===
As noted above, at the end of the previous section, widely-used terminology distinguishes '''object-''oriented''''' programming from '''[[object-based programming|object-''based]]''''' programming. The former is held to include inheritance (described below), while the latter does not.
[[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====
The exact definitions of some of these terms show some variation, depending on point of view. In particular, languages with [[static typing]] often reflect and embody slightly different views of OO from those reflected by and embodied in languages with [[dynamic typing]], due to a focus on the compile-time rather than the run-time properties of programs.
 
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:
Note: Abstraction is important, but not unique, to OOP. Other programming paradigms employ it as well.
 
* [[Class variable]] – belongs to the class itself; all objects of the class share one copy
[[Reusability]] is the benefit most often claimed for OOP. However, that claim is unlikely to be true, as reuse of software is as old as the [[David Wheeler|invention of the subroutine]], reputedly prior to 1950. In fact,
* [[Instance variable]] – belongs to an object; every object has its own version of these variables
reuse is frequently disputed as being a primary, or even a large, benefit. The ease of translation to and from the target environment, the (improved) ability to maintain a program once written, the ability to do localized debugging, and the (improved) ability to do much larger parallel development efforts, are all cited as more significant reasons to use an OOP language.
* [[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.
OOP is often called a [[paradigm]] rather than a style or type of programming, to emphasize the point that OOP can change the way [[software]] is developed by actually changing the way in which [[programmer]]s and [[software engineer]]s ''think'' about software. As a paradigm, OOP is about overall system design as much as it is about programming. A system is designed by defining the objects that will exist and interact within the system. Due to encapsulation, the code that actually does the work is irrelevant to an object, and to the people using the object. The challenge in OOP, therefore, is of designing a sane object system.
 
An [[abstract class]] cannot be directly instantiated as an object. It is only used as a super-class.
It should be noted that there are distinct parallels between the object-oriented paradigm and [[systems theory]]. OOP focuses on objects as units in a system, whereas systems theory focuses on the system itself. In between, one may find software [[design patterns]] or other techniques that use classes and objects as building blocks for larger components. Such components can be seen as an intermediate step from the object-oriented paradigm towards the more "real-life oriented" models of systems theory.
 
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}}
===Actor model===
OOP is a decomposition paradigm for program code, not a model for computation.
 
====Prototype-based====
OOP is often confused with the [[Actor model]] of computation. In response to a message that it receives, an Actor can make local decisions, create more Actors, send more messages, and determine how to respond to the next message received.
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.
Almost all OOP languages and systems, including all the major ones, such as [[SIMULA]], [[Smalltalk]], [[C++]], [[Java programming language|Java]], [[Ruby programming language|Ruby]], [[Python programming language|Python]], Delphi, VB .NET, and [[C sharp|C#]], have [[message passing programming]] capabilities.
 
====No inheritance====
See [[Actor model implementation|Actor model implementations]] for a discussion on implementations of the Actor model.
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>
In OOP the emphasis is not on how computation is organized, but on how program '''text''' is decomposed into modules, because it is this decomposition that matters as to the program text's comprehensibility and maintainability.
 
====Inheritance and behavioral subtyping====
OOP is based on the assumption that the program text's comprehensibility and maintainability are improved by decomposing the text into modules, and that the best way to decompose it into modules is to minimize dependencies among modules and maximize the cohesion of functions inside each module, and that this is best achieved by encapsulating the representation of a data type in each module.
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===
There are several distinct styles of object-oriented programming. The distinctions between different styles occur because different programming languages emphasize different aspects of object-oriented facilities and combine with other constructs in different ways.
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.
===OOP with procedural languages===
In procedural languages, OOP often appears as a form where [[data type]]s are extended to behave like a type of an object in OOP, very similar to an [[abstract data type]] with an extension such as [[inheritance (computer science)|inheritance]]. Each [[method (computer science)|method]] is actually a [[subprogram]] which is syntactically bound to a class.
 
===Message passing===
=== Static typing with the object-oriented paradigm ===
[[Message passing]] is when the method name and its inputs are sent like a message to the object for it to act on.
Many object-oriented programming languages, such as [[C++]] and [[Java programming language|Java]], have a static [[type system]] that can be used to check and enforce constraints of [[object-oriented design]] to some extent at compile-time, i.e. ''statically''.
Object-oriented facilities combine with static typing in various ways. [[class (computer science)|Class]]es are types of objects.
Many object-oriented languages provide mechanisms for statically checking the type of method parameters, types of private and public data members, types of object references and check the correctness of inheritance and subtyping relationships.
Static type checking can also check [[application programming interface|API]] compatibility, enforce data constraints on the users of libraries created with object-oriented methods and reduce the number of type checks performed at run-time for various forms of method dispatch.
 
===Polymorphism===
Some object-oriented languages, such as [[Eiffel programming language|Eiffel]], supplement the type system with [[Assertion (computing)|assertion]]s specifying and documenting [[invariant (computer science)|invariant]]s of classes and the [[design by contract|contract]]s of methods, though current Eiffel compilers only check these at run-time, i.e. ''dynamically''.
[[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]].
See [[Class-based OOP]].
 
===Prototype-basedOpen modelrecursion===
Other than using classes, '''prototyping''' is another, less popular, means of achieving object-oriented behavior sharing. After an object is defined, another similar object will be defined by referring to the original one as a template, then listing the new object's differences from the original. Perhaps the most popular prototype-based language is [[JavaScript]], which is an implementation of [[ECMAScript]]. In prototyping systems, objects themselves are the templates, while classification systems use classes as templates for objects.
 
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]].
The classification approach is so predominant in OOP that many people would define objects as encapsulations that share data by classification and inheritance. However, the more generic term "behavior sharing" acknowledges alternate techniques such as prototyping.
 
==Design patterns==
See [[Prototype-based programming]].
[[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-based modelpatterns===
Object-based '''programming''' is centered around the creation of objects and their interactions, but may not have some of the key features of the class-based object-oriented paradigm such as inheritance. Such object-based systems are usually not regarded as object-oriented, because inheritance (viewing [[delegation (computer science)|delegation]] as a form of inheritance) is typically identified as the core feature of OOP.
 
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>
===Multimethod model===
In this model, the "'''receiver'''" argument to a message is not given special status in message dispatch. Instead, the runtime values of all arguments to message are consulted to determine which method should be executed at runtime. This is related to [[double dispatch |double]] or multimethod dispatch.
 
*[[Function object]]: Class with one main method that acts like an [[anonymous function]] (in C++, the function operator, {{code|operator()}})
Note that some feel th
*[[Immutable object]]: does not change state after creation
at set theory or predicate logic is better suited to tackle this kind of complexity.
*[[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.
==Possible programming mistakes==
There are several common mistakes which programmers can make in object oriented programming. For example, checking the type of an object rather than its membership is a common pitfall, or [[antipattern]], that counteracts the benefits of inheritance and polymorphism.
 
===Gang of Four design patterns===
==Critique==
{{Main|Design pattern (computer science)}}
'''OOP and Code Maintenance''' :
OOP and OOP languages by design support code centrality (e.g. through inheritance) which according to some critics increases code maintenance cost (especially for medium to large code based applications) as one bad change at higher level of hierarchy can have manifold impact through out the system. Given employee turnover ratio in IT industry is towards higher end and the new replacement will not be as code aware as older one this aspect assumes more importance. Its a very common observation among developers that those maintaining base level classes tend to avoid code changes to fix a bug (esp near milestone dates) and tend to ask developers maintaining leaf level classes to override the function at their class level to fix the same. Though through procedural language also one achieves code centrality through methods which are private in nature (i.e. the ones which are not directly accessed externally) but its a bit easier to avoid there.
 
''[[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.
According to some critics of OOP, hierarchical taxonomies and lists of mutually-exclusive options often do not match the real world and real-world changes, and therefore should be avoided. Many OOP proponents also suggest avoiding hierarchies, and instead using OO techniques such as "[[Object composition|composition]]". Critics of composition consider it too similar to the network data structures that relational was meant to replace. (More on this below.)
 
These solutions, called "design patterns," are grouped into three types:
A simple way of avoiding over-specification of hierarchies when modeling the real world is to consider only the most specific types of objects possible, and to model relationships only between those. But deviations from hierarchies tend to complicate the use of single inheritance and "sub-type" based polymorphism.
 
* ''[[Creational pattern]]s'' (5): [[Factory method pattern]], [[Abstract factory pattern]], [[Singleton pattern]], [[Builder pattern]], [[Prototype pattern]]
Some critics allege that the [[relational model]] is a superior categorization and large-scale structuring tool due to its mathematical foundations in [[predicate calculus]], [[relational calculus]], and [[set theory]]. OOP is not based on a consensus mathematical model.
* ''[[Structural pattern]]s'' (7): [[Adapter pattern]], [[Bridge pattern]], [[Composite pattern]], [[Decorator pattern]], [[Facade pattern]], [[Flyweight pattern]], [[Proxy 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]]
 
===Object-orientation and databases===
Some critics feel that OOP reverts back to the [[navigational database]] arrangements of the 1960s, which have since been replaced by relational techniques. It is not clear that this is a fault of OOP, since relational database modeling is possibly based on different fundamental premises from those on which object-oriented modeling is based. In any case, relational database tables can map to associations in object-oriented models, and the differences seem to be due to differences in focus, according to defenders.
{{Main|Object-relational impedance mismatch|Object-relational mapping|Object database}}
 
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 is a history of misinterpretation of the relationship between object-oriented and relational modeling, which may muddy this issue. Also, there are differences in opinion about the roles and definitions of each.
 
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.
For example, some critics of OOP believe that it leads to unnecessary copying of noun relationship information from a database, even though the "once and only once" (i.e., no duplication) mantra would indicate that such is bad practice.
 
Some databases, called [[object database]]s, are designed to work with OOP. However, they have not been as popular or successful as relational databases.
In contrast, others maintain that even though some existing OOP-to-relational database products mistakenly use a duplicative approach -- confusing an ''object's'' data with ''relationship'' data -- OOP principles do not ''intrinsically require'' this duplication of data. These people argue that strict distinctions should be made between data associated with modelled objects, data associated with roles, and data associated with associations. On this view, objects' data should not be (directly) stored in databases, because databases are not a suitable storage mechanism for objects, because every object already has some other mechanism for storing its private information, and because, as already noted, storage in a database would require unnecessary duplication between an object's image in its own storage and in the database.
 
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>
The conflict or discrepancy, or "[[Object-Relational_impedance_mismatch |impedance mismatch]]", between OOP and the relational approach to databases is caused by differences of scale and focus between operations performed by objects and those performed by databases. Database transactions — the smallest unit of work performed by database management systems (DBMSes) — are much larger than any operations performed by OOP objects. On this view, databases are good for storing relationships between objects, and the references to objects that are associated with the roles that those relationships are built on, but objects' data should only be stored in databases after collecting and summarising data from groups of objects. Objects' private representation details have no place in databases.
 
===Responsibility- vs. data-driven design===
Others argue that if objects are only meant to be small and local, then there is little need for the complexity and performance overhead of OOP. Is the "big model" of ___domain nouns to be in the database or in classes? Duplication factoring would dictate that it be in only one or the other.
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>
 
===SOLID and GRASP guidelines===
Needless to say, the "proper" relationship between OOP and databases is a complex and contentious topic which currently has no consensus solution.
[[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.
While it is claimed that OOP is better for "large applications", others feel that large applications should instead be reduced to many small applications, such as [[event-driven programming|event-driven]] procedures that "feed" off a database and [[declarative programming]]-based user interface frameworks.
* [[Open/closed principle]]: Software entities should be open for extension, but closed for modification.
* [[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>
The bottom line of the conflict seems to be that OOP is mostly a behaviorist view of software design which conflicts with the data-centric, declarative view. In the first, the "interfaces" are primarily behaviors, and data is grouped into objects. In the second, the interfaces are primarily data (declarations), and behaviours are grouped into functions, such as "tasks", or "events". The tradeoffs of each approach are complex; choosing among them often requires one to delve deep into theories of human psychology. Sometimes both approaches are used, such that OOP is used to build [[platform (computing)|platform]] facilities, and a functional or declarative method is used to build [[application software|applications]] for the platform.
 
* Creator Principle: allows classes create objects they closely use.
Some feel that past criticisms leveled against procedural techniques are based upon poor languages, poor coding practices, or lack of knowledge about how to properly use databases instead of code to manage state and "noun models".
* Information Expert Principle: assigns tasks to classes with the needed information.
* Low Coupling Principle: reduces class dependencies to improve flexibility and maintainability.
* High Cohesion Principle: designing classes with a single, focused responsibility.
* Controller Principle: assigns system operations to separate classes that manage flow and interactions.
* 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==
It is recognized that OOP does not necessarily mean lack of complexity. Metaclass programming for example is a demanding skill, and OOP programs can have a complex web of shared or distinct responsibilities, attributes and methods. It can be challenging to distribute [[responsibility]] over objects, or classes&mdash;one of many popular [[implementation]] schemes.
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<sub><:</sub>]] 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==
==Formal definition==
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>
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:
 
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"/>
Attempts to find a consensus definition or theory behind objects have not proven very successful, 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").
 
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>
==OOP in scripting==
In recent years, object-based programming has become especially popular in [[scripting programming language]]s, with [[abstraction]], [[Information hiding|encapsulation]], [[reusability]], and ease of use being the most commonly cited reasons, (the value of [[Inheritance (computer science)|inheritance]] in these languages is often questioned). [[Smalltalk]] is probably the first language that fits into this category. [[Python programming language|Python]] and [[Ruby programming language|Ruby]] are relatively recent languages that were built from the ground up with OOP in mind, while the popular [[Perl]] and [[PHP]] scripting languages have been slowly adding new object oriented features since versions 5 and 4, respectively. The ability of objects to represent "real world" entities is one reason for the popularity of JavaScript and ECMAScript, which is argued to be well suited to representing the [[Document Object Model]] of [[HTML]] and [[XML]] documents on the Internet.
 
==HistorySee also==
{{Portal|Computer programming}}
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]].
* [[CADES]]
* [[Common Object Request Broker Architecture]] (CORBA)
* [[Comparison of programming languages (object-oriented programming)]]
* [[Component-based software engineering]]
* [[Distributed Component Object Model]]
* [[Interface description language]]
* [[IDEF4]]
* [[Jeroo]]
* [[List of object-oriented programming languages]]
* [[Object association]]
* [[Object-oriented analysis and design]]
* [[Object-oriented modeling]]
* [[Object-oriented ontology]]
* [[UML]]
 
==References==
Objects as programming entities were introduced in [[Simula|Simula 67]], a programming language designed for making simulations, created by [[Ole-Johan Dahl]] and [[Kristen Nygaard]] of the [[Norwegian Computing Centre]] 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]].) Such an approach was a simple extrapolation of concepts earlier used in ''analog'' programming. On ''analog'' computers, such direct 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.
{{Reflist}}
 
The [[Smalltalk]] language, which was developed at [[Xerox PARC]], 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 objects could be created, modified, and 'consumed' "on the fly" rather than having a system based on static objects. It also introduced the notion of 'inheritance.' (Thus, Smalltalk was clearly a major move beyond the analog programming models, which made no use of "instances of classes," or even Simula, which made no use of the "inheritance property.")
 
The ideas in [[Simula|Simula 67]] were also used in many other languages, from derivatives of [[Lisp programming language|Lisp]] to [[Pascal programming language|Pascal]].
 
Object-oriented programming developed as the dominant programming methodology during the mid-1980s, largely due to the influence of [[C++]], an extension of the [[C programming language]]. Its dominance was further cemented by the rising popularity of [[Graphical user interface]]s, for which object-oriented programming is allegedly 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 GUI's (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 [[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++.
 
Object-oriented features have been added to many existing languages during that time, including [[Ada programming language|Ada]], [[BASIC programming language|BASIC]], [[Lisp programming language|Lisp]], [[Fortran|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. "Pure" object-oriented languages, on the other hand, lacked features that many programmers had come to depend upon. To bridge this gap, many attempts have been made to create new languages based on object-oriented methods but allowing some procedural features in "safe" ways. Bertrand Meyer's [[Eiffel programming language|Eiffel]] was an early and moderately successful language with those goals.
 
In the past decade [[Java programming language|Java]] has emerged in wide use partially because of its similarity to [[C language|C]] and to [[C++]], but perhaps more importantly because of its implementation using a [[Virtual machine | 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.
 
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]] and [[C Sharp|C#]] designed for Microsoft's [[.NET Framework|.NET]] platform.
 
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]]).
 
==Further reading==
* {{Cite book
{{wikibookspar||Computer programming/Object oriented programming}}
|first1=Martin
 
|last1=Abadi
*{{cite book
|firstauthor-link=Martin Abadi
|author2=Luca Cardelli
|last=Abadi
|year=1998
|authorlink=Martin Abadi
|coauthors=[[Luca Cardelli]]
|year=
|title=A Theory of Objects
|publisher=[[Springer- Verlag]]
|idisbn=ISBN 978-0-387-94775-24
|author2-link=Luca Cardelli
}}
* {{Cite book
|first1=Harold
|last1=Abelson
|author-link=Harold Abelson
|author2=Gerald Jay Sussman
|year=1997
|title=Structure and Interpretation of Computer Programs
|url=http://mitpress.mit.edu/sicp/
|publisher=[[MIT Press]]
|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 bookjournal
|first1=Deborah J.
|first=Harold
|last1=Armstrong
|last=Abelson
|date=February 2006
|authorlink=Harold Abelson
|title=The Quarks of Object-Oriented Development
|coauthors=[[Gerald Jay Sussman]], [[Julie Sussman]]
|journal=Communications of the ACM
|year=
|volume=49
|title=[http://mitpress.mit.edu/sicp/ Structure and Interpretation of Computer Programs]
|issue=2
|publisher=The MIT Press
|pages=123–128
|id=ISBN 0262011530
|issn=0001-0782
|doi=10.1145/1113034.1113040
|s2cid=11485502
}}
*{{cite book
|title="Effective Java: Programming Language Guide"
|first=Grady
|last1=Bloch
|last=Booch
|first1=Joshua
|authorlink=Grady Booch
|publisher=Addison-Wesley
|year=
|edition=third
|isbn=978-0134685991
|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
|id=ISBN 0805353402
|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]]
|idisbn=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-0
|id=ISBN 0201633612
|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
|idisbn=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
|id=ISBN 0201544350
|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-8
|id=ISBN 0136291554
|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-0
|id=ISBN 0136298419
|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
|idisbn=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
}}
 
{{col-begin}}
{{col-2}}
 
==See also==
*[[Object-oriented programming language]]
*[[Aspect-oriented programming]]
*[[Programming paradigm]]
*[[Software componentry]]
*[[Interface description language]]
*[[Distributed programming]]
*[[List of object-oriented programming terms]]
*[[Design pattern (computer science)]]
*[[Refactoring]]
*[[CORBA]]
*[[Globus]]
*[[DCOM]]
*[[Object-relational mapping]]
*[[Object database]]
{{col-2}}
 
==External links==
{{Wikiquote|Object-orientation}}
*[http://www.objectfaq.com/oofaq2/ Object-oriented programming FAQ]
{{Wikiversity|at=Topic:Object-Oriented Programming}}
*[http://okmij.org/ftp/Computation/Subtyping/#Problem Example of the subtyping problem]
{{Wikibooks|Object Oriented Programming}}
*[http://xahlee.org/Periodic_dosage_dir/t2/oop.html What are OOP's Jargons and Complexities]
* [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
*[http://www.eventhelix.com/RealtimeMantra/Object_Oriented/ Object Oriented Design Principles]
*[https://thenewstack.io/why-are-so-many-developers-hating-on-object-oriented-programming/ Discussion on Cons of OOP]
*The report [http://www.interaction-design.org/mads/articles/object_orientation_redefined.html "Object Orientation Redefined"] outlines how OO has been considered a thinking tool, i.e. "we view the world in objects", and how such an approach may further our understanding of object-oriented formalisation.
* [http://java.sun.com/docs/books/tutorial/java/concepts/ OOP Concepts (Java Tutorials)]
*[http://objectdiscovery.com/papers/roles/index.html Modeling Roles : A practical series of Analysis Patterns ] How to easily identify a Role problem and precisely determine which Role analysis pattern is best to model it.
 
===Criticism===
*[http://dreamsongs.com/ObjectsHaveFailedNarrative.html Objects Have Failed]
*[http://c2.com/cgi/wiki?ArgumentsAgainstOop Arguments Against OOP (C2 wiki discussion)]
*[http://www.devx.com/opinion/Article/26776 OOP Better in Theory than in Practice]
*[http://www.paulgraham.com/noop.html Why Paul Graham is Creating a New Language Not Especially Object-Oriented]
{{col-end}}
 
[[Category:Object-oriented programming]]
 
{{Programming paradigms navbox}}
{{Link FA|vi}}
{{Types of programming languages}}
{{Software engineering}}
{{Authority control}}
 
{{DEFAULTSORT:Object-Oriented Programming}}
[[ar:برمجة شيئية]]
[[Category:Object-oriented programming| ]]
[[bg:Обектно-ориентирано програмиране]]
[[Category:Programming paradigms]]
[[bs:Objektno Orijentirano Programiranje]]
<!-- Hidden categories below -->
[[ca:Orientació a objectes]]
[[Category:Articles with example code]]
[[cs:Objektově orientované programování]]
[[da:Objektorienteret programmering]]
[[de:Objektorientierte Programmierung]]
[[eo:Objektema programado]]
[[es:Programación orientada a objetos]]
[[eu:Objektuei orientatutako programazio]]
[[fi:Olio-ohjelmointi]]
[[fr:Programmation orientée objet]]
[[he:תכנות מונחה עצמים]]
[[hu:Objektumorientált programozás]]
[[id:Pemrograman Berorientasi Objek]]
[[io:Objektema programado]]
[[it:Programmazione orientata agli oggetti]]
[[ja:オブジェクト指向]]
[[lt:Objektinis programavimas]]
[[ms:Pengaturcaraan Berorientasikan Objek]]
[[nl:Objectoriëntatie]]
[[no:Objektorientert programmering]]
[[pl:Programowanie obiektowe]]
[[pt:Orientação a objeto]]
[[ru:Объектно-ориентированное программирование]]
[[sv:Objektorienterad programmering]]
[[th:การเขียนโปรแกรมเชิงวัตถุ]]
[[tr:Nesne Yönelimli Programlama]]
[[uk:Об’єктно-орієнтоване програмування]]
[[vi:Lập trình hướng đối tượng]]
[[zh:面向对象的程序设计]]
[[ko:객체지향 프로그래밍]]