Content deleted Content added
wrangle the sections, they were repeating the same concepts and overlapped |
remove criticism section per WP:CSECTION, spread it out in other sections. A lot ended up in a new "popularity" section |
||
Line 4:
{{Programming paradigms}}
'''Object-oriented programming''' ('''OOP''') is a [[programming paradigm]] based on the concept of ''[[Object (computer science)|objects]]'',<ref name=alanKayOnOO /> which can contain [[data]] and [[source-code|code]]: data in the form of [[Field (computer science)|fields]] (often known as [[Attribute (computing)|attributes]] or [[Property (programming)|properties]]), and code in the form of [[Procedure (computer science)|procedures]] (often known as [[method (computing)|methods]]). In OOP, [[computer program]]s are designed by making them out of objects that interact with one another.<ref>{{Cite journal
| last1 = Kindler | first1 = E.
| last2 = Krivy | first2 = I.
Line 82 ⟶ 80:
[[File:oop-uml-class-example.png|frame|right|[[Unified Modeling Language|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.]]
{{See also|Comparison of programming languages (object-oriented programming)|List of object-oriented programming terms}}
Object-oriented programming uses objects, but not all of the associated techniques and structures are supported directly in languages that claim to support OOP. It performs operations on operands. The features listed below are common among languages considered to be strongly class- and object-oriented (or [[multi-paradigm]] with OOP support), with notable exceptions mentioned.<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|last=Pierce|first=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> [[Christopher J. Date]] stated that critical comparison of OOP to other technologies, relational in particular, is difficult because of lack of an agreed-upon and rigorous definition of OOP.<ref name="DatePage650">C. J. Date, Introduction to Database Systems, 6th-ed., Page 650</ref>
===Shared with non-OOP languages===
Line 93 ⟶ 91:
Objects sometimes correspond to things found in the real world. For example, a graphics program may have objects such as "circle", "square", and "menu". An online shopping system might have objects such as "shopping cart", "customer", and "product".<ref>{{cite book|last=Booch|first=Grady|title=Software Engineering with Ada|year=1986|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> Sometimes objects represent more abstract entities, like an object that represents an open file, or an object that provides the service of translating measurements from U.S. customary to metric. Objects are accessed somewhat like variables with complex internal structures, and in many languages are effectively [[Pointer (computer programming)|pointers]], serving as actual references to a single instance of said object in memory within a heap or stack. Procedures are known as [[Method (computer science)|methods]]; variables are also known as [[Field (computer science)|fields]], members, attributes, or properties.
Objects can contain other objects in their instance variables; this is known as [[object composition]]. For example, an object in the Employee class might contain (either directly or through a pointer) an object in the Address class, in addition to its own instance variables like "first_name" and "position". Object composition is used to represent "has-a" relationships: every employee has an address, so every Employee object has access to a place to store an Address object (either directly embedded within itself or at a separate ___location addressed via a pointer). Date and Darwen have proposed a theoretical foundation that uses OOP as a kind of customizable [[data type|type system]] to support [[RDBMS]].<ref name="ThirdManifesto">C. J. Date, Hugh Darwen. ''Foundation for Future Database Systems: The Third Manifesto'' (2nd Edition)</ref>
The OOP paradigm has been criticized for overemphasizing the use of objects for software design and modeling at the expense of other important aspects (computation/algorithms).<ref name="stepanov"/><ref name="hickey"/> For example, [[Rob Pike]] has said that OOP languages frequently shift the focus from [[data structure]]s and [[algorithm]]s to [[data type|types]].<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> [[Steve Yegge]] noted that, as opposed to [[functional programming]]:<ref name="yegge">{{Cite web|url=http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html|title=Stevey's Blog Rants: Execution in the Kingdom of Nouns|access-date=20 May 2020}}</ref>
{{quote|Object Oriented Programming puts the nouns first and foremost. Why would you go to such lengths to put one part of speech on a pedestal? Why should one kind of concept take precedence over another? It's not as if OOP has suddenly made verbs less important in the way we actually think. It's a strangely skewed perspective.}}▼
[[Rich Hickey]], creator of [[Clojure]], described object systems as overly simplistic models of the real world. He emphasized the inability of OOP to model time properly, which is getting increasingly problematic as software systems become more concurrent.<ref name="hickey">Rich Hickey, JVM Languages Summit 2009 keynote, [http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey Are We There Yet?] November 2009.</ref>▼
[[Alexander Stepanov]] compares object orientation unfavourably to [[generic programming]]:<ref name="stepanov">{{Cite web| url=http://www.stlport.org/resources/StepanovUSA.html| title=STLport: An Interview with A. Stepanov| last=Stepanov| first=Alexander| access-date=21 April 2010| author-link=Alexander Stepanov}}</ref>▼
{{quote|I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras — families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting — saying that everything is an object is saying nothing at all.}}▼
===Inheritance===
Line 112 ⟶ 120:
In contrast, in [[prototype-based programming]], ''objects'' are the primary entities. Generally, the concept of a "class" does not even exist. Rather, the ''prototype'' or ''parent'' of an object is just another object to which the object is linked. 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, every object has one ''prototype'' link (and only one). New objects can be created based on already existing objects chosen as their prototype. You may call two different objects ''apple'' and ''orange'' a fruit if the object ''fruit'' exists, and both ''apple'' and ''orange'' have ''fruit'' as their prototype. The idea of the ''fruit'' class does not exist explicitly, but can be modeled as the [[equivalence class]] of the objects sharing the same prototype, or as the set of objects satisfying a certain interface ([[duck typing]]). Unlike class-based programming, it is typically possible in prototype-based languages to define attributes and methods not shared with other objects; for example, the attribute ''sugar_content'' may be defined in ''apple'' but not ''orange''.
The doctrine of [[composition over inheritance]] advocates implementing has-a relationships using composition instead of inheritance. For example, instead of inheriting from class Person, class Employee could give each Employee object an internal Person object, which it then has the opportunity to hide from external code even if class Person has many public attributes or methods. Some languages like [[Go (programming language)|Go]] do not support inheritance at all. Go states that it is object-oriented,<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> and Bjarne Stroustrup, author of C++, has stated that it is possible to do OOP without inheritance.<ref>{{cite conference |last1=Stroustrup |first1=Bjarne |title=Object-Oriented Programming without Inheritance (Invited Talk) |date=2015 |doi=10.4230/LIPIcs.ECOOP.2015.1|url=https://www.youtube.com/watch?v=xcpSLRpOMJM|conference=29th European Conference on Object-Oriented Programming (ECOOP 2015)|at=1:34}}</ref> [[Delegation (object-oriented programming)|Delegation]] is another language feature that can be used as an alternative to inheritance. [[Rob Pike]] has called object-oriented programming "the [[Roman numerals]] of computing"<ref>{{cite mailing list |url=http://groups.google.com/group/comp.os.plan9/msg/006fec195aeeff15 |title=[9fans] Re: Threads: Sewing badges of honor onto a Kernel |date=2 March 2004 |access-date=17 November 2016 |mailing-list=comp.os.plan9 |last=Pike |first=Rob |author-link=Rob Pike}}</ref> and cites an instance of a [[Java (programming language)|Java]] professor whose "idiomatic" solution to a problem was to create six new classes, rather than to simply use a [[lookup table]].<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>
===Dynamic dispatch/message passing===
Line 122 ⟶ 132:
Data [[Abstraction (computer science)|abstraction]] is a design pattern in which data are visible only to semantically related functions, to prevent misuse. The success of data abstraction leads to frequent incorporation of [[Information hiding|data hiding]] as a design principle in object-oriented and pure functional programming. Similarly, [[Encapsulation (computer programming)|encapsulation]] prevents external code from being concerned with the internal workings of an object. This facilitates [[code refactoring]], for example allowing the author of the class to change how objects of that class represent their data internally without changing any external code (as long as "public" method calls work the same way). It also encourages programmers to put all the code that is concerned with a certain set of data in the same class, which organizes it for easy comprehension by other programmers. Encapsulation is a technique that encourages [[Coupling (computer programming)|decoupling]].
In object oriented programming, objects provide a layer which can be used to separate internal from external code and implement abstraction and encapsulation. External code can only use an object by calling a specific instance method with a certain set of input parameters, reading an instance variable, or writing to an instance variable. A program may create many instances of objects as it runs, which operate independently. This technique, it is claimed, allows easy re-use of the same procedures and data definitions for different sets of data, in addition to potentially mirroring real-world relationships intuitively. Rather than utilizing database tables and programming subroutines, the developer utilizes objects the user may be more familiar with: objects from their application ___domain.<ref>{{cite book|last=Jacobsen|first=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> These claims that the OOP paradigm enhances reusability and modularity have been criticized.<ref name="badprop"/><ref name="armstrongjoe"/>
If a class does not allow calling code to access internal object data and permits access through methods only, this is also a form of information hiding. Some languages (Java, for example) let classes enforce access restrictions explicitly, for example, denoting internal data with the <code>private</code> keyword and designating methods intended for use by code outside the class with the <code>public</code> keyword.{{sfn|Bloch|2018|loc=Chapter §4 Item15 Minimize the accessibility of classes and members|pp=73-77}} Methods may also be designed public, private, or intermediate levels such as <code>protected</code> (which allows access from the same class and its subclasses, but not objects of a different class).{{sfn|Bloch|2018|loc=Chapter §4 Item15 Minimize the accessibility of classes and members|pp=73-77}} In other languages (like Python) this is enforced only by convention (for example, <code>private</code> methods may have names that start with an [[underscore]]). In C#, Swift & Kotlin languages, <code>internal</code> keyword permits access only to files present in the same assembly, package, or module as that of the class.<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}}</ref>
In programming languages, particularly object-oriented ones, the emphasis on abstraction is vital. Object-oriented languages extend the notion of type to incorporate data abstraction, highlighting the significance of restricting access to internal data through methods.<ref>{{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> [[Eric S. Raymond]] has written that object-oriented programming 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|author=Eric S. Raymond|date=2003|access-date=6 August 2014}}</ref> Raymond compares this unfavourably to the approach taken with Unix and the [[C (programming language)|C programming language]].<ref name="Eric S. Raymond 2003"/>
The "[[
{{quote|The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.}}▼
Leo Brodie has suggested a connection between the standalone nature of objects and a tendency to [[duplicate code]]<ref>{{Cite book| url=http://thinking-forth.sourceforge.net/thinking-forth-ans.pdf| title=Thinking Forth| last=Brodie| first=Leo|pages=92–93 |year=1984 |access-date=4 May 2018}}</ref> in violation of the [[don't repeat yourself]] principle<ref>{{cite web| work=Category Extreme Programming| last=Hunt| first=Andrew| url=http://wiki.c2.com/?DontRepeatYourself|title=Don't Repeat Yourself| access-date=4 May 2018}}</ref> of software development.▼
===Polymorphism===
Line 138 ⟶ 152:
===Open recursion===
A common feature of objects is that methods are attached to them and can access and modify the object's data fields. In this brand of OOP, there is usually a special name such as [[this (computer programming)|{{code|this|C++}}]] or {{code|self|swift}} used to refer to the current object. In languages that support [[open recursion]], object methods can call other methods on the same object (including themselves)
=={{Anchor|Object-oriented source code}}OOP languages==
Line 152 ⟶ 166:
* Languages with [[abstract data type]] support which may be used to resemble OO programming, but without all features of object-orientation. This includes [[object-based|object-''based'']] and [[Prototype-based programming|prototype-based]] languages. Examples: [[JavaScript]], [[Lua (programming language)|Lua]], [[Modula-2]], [[CLU (programming language)|CLU]].
* Chameleon languages that support multiple paradigms, including OO. [[Tcl]] stands out among these for TclOO, a hybrid object system that supports both [[prototype-based programming]] and class-based OO.
=== Popularity and reception ===
Many widely-used languages, such as C++, Java, and Python, provide object-oriented features. Although in the past object-oriented programming was widely accepted,<ref>{{cite journal |last1=Brucker |first1=Achim D. |last2=Wolff |first2=Burkhart |title=Extensible Universes for Object-Oriented Data Models |journal=ECOOP 2008 – Object-Oriented Programming |date=2008 |volume=5142 |pages=438–462 |doi=10.1007/978-3-540-70592-5_19|quote=object-oriented programming is a widely accepted programming para-
digm}}</ref> more recently essays criticizing object-oriented programming and recommending the avoidance of these features (generally in favor of [[functional programming]]) have been very popular in the developer community.<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> [[Paul Graham (computer programmer)|Paul Graham]] has suggested that OOP's popularity within large companies is due to "large (and frequently changing) groups of mediocre programmers". According to Graham, the discipline imposed by OOP prevents any one programmer from "doing too much damage".<ref name="graham">{{Cite web| last=Graham| first=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, has been critical of claims that present object-oriented programming as the "One True Solution".<ref name="Eric S. Raymond 2003"/>▼
Richard Feldman argues that these languages may have improved their modularity by adding OO features, but they became popular for reasons other than being object-oriented.<ref>{{cite web |last1=Feldman |first1=Richard |title=Why Isn't Functional Programming the Norm? |url=https://www.youtube.com/watch?v=QyJZzq0v7Z4&t=2069s |language=en}}</ref> In an article, Lawrence Krubner claimed that compared to other languages (LISP dialects, functional languages, etc.) OOP languages have no unique strengths, and inflict a heavy burden of unneeded complexity.<ref name="lawrence">{{Cite web| last=Krubner| first=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> A study by Potok et al. has shown no significant difference in productivity between OOP and procedural approaches.<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| last=Potok| first=Thomas|author2=Mladen Vouk |author3=Andy Rindos |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> [[Luca Cardelli]] has claimed that OOP code is "intrinsically less efficient" than procedural code and that OOP can take longer to compile.<ref name="badprop">{{Cite journal| first=Luca| last=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}}</ref>
===OOP in dynamic languages===
Line 212 ⟶ 233:
[[GRASP (object-oriented design)|GRASP]] (General Responsibility Assignment Software Patterns) is another set of guidelines advocated by [[Craig Larman]].
▲[[Luca Cardelli]] has claimed that OOP code is "intrinsically less efficient" than procedural code, that OOP can take longer to compile, and that OOP languages have "extremely poor modularity properties with respect to class extension and modification", and tend to be extremely complex.<ref name="badprop">{{Cite journal| first=Luca| last=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}}</ref> The latter point is reiterated by [[Joe Armstrong (programming)|Joe Armstrong]], the principal inventor of [[Erlang (programming language)|Erlang]], who is quoted as saying:<ref name="armstrongjoe">Armstrong, Joe. In ''Coders at Work: Reflections on the Craft of Programming.'' Peter Seibel, ed. [http://www.codersatwork.com/ Codersatwork.com] {{Webarchive|url=https://web.archive.org/web/20100305165150/http://www.codersatwork.com/ |date=5 March 2010 }}, Accessed 13 November 2009.</ref>
▲{{quote|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.}}
▲[[Alexander Stepanov]] compares object orientation unfavourably to [[generic programming]]:<ref name="stepanov">{{Cite web| url=http://www.stlport.org/resources/StepanovUSA.html| title=STLport: An Interview with A. Stepanov| last=Stepanov| first=Alexander| access-date=21 April 2010| author-link=Alexander Stepanov}}</ref>
▲{{quote|I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras — families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting — saying that everything is an object is saying nothing at all.}}
▲[[Paul Graham (computer programmer)|Paul Graham]] has suggested that OOP's popularity within large companies is due to "large (and frequently changing) groups of mediocre programmers". According to Graham, the discipline imposed by OOP prevents any one programmer from "doing too much damage".<ref name="graham">{{Cite web| last=Graham| first=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>
▲Leo Brodie has suggested a connection between the standalone nature of objects and a tendency to [[duplicate code]]<ref>{{Cite book| url=http://thinking-forth.sourceforge.net/thinking-forth-ans.pdf| title=Thinking Forth| last=Brodie| first=Leo|pages=92–93 |year=1984 |access-date=4 May 2018}}</ref> in violation of the [[don't repeat yourself]] principle<ref>{{cite web| work=Category Extreme Programming| last=Hunt| first=Andrew| url=http://wiki.c2.com/?DontRepeatYourself|title=Don't Repeat Yourself| access-date=4 May 2018}}</ref> of software development.
▲{{quote|Object Oriented Programming puts the nouns first and foremost. Why would you go to such lengths to put one part of speech on a pedestal? Why should one kind of concept take precedence over another? It's not as if OOP has suddenly made verbs less important in the way we actually think. It's a strangely skewed perspective.}}
▲[[Rich Hickey]], creator of [[Clojure]], described object systems as overly simplistic models of the real world. He emphasized the inability of OOP to model time properly, which is getting increasingly problematic as software systems become more concurrent.<ref name="hickey">Rich Hickey, JVM Languages Summit 2009 keynote, [http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey Are We There Yet?] November 2009.</ref>
▲Regarding inheritance, [[Robert C. Martin|Bob Martin]] states that because they are software, related classes do not necessarily share the relationships of the things they represent.<ref>{{cite web | url=https://www.youtube.com/watch?v=zHiWqnTWsn4 | title=Uncle Bob SOLID principles | website=[[YouTube]] }}</ref>
==Formal semantics==
| |||