Content deleted Content added
Reverting edit(s) by 172.59.120.127 (talk) to rev. 1256782476 by Jarble: Non-constructive edit (UV 0.1.6) |
mNo edit summary |
||
| (66 intermediate revisions by 28 users not shown) | |||
Line 1:
{{short description|Programming paradigm based on
{{Use dmy dates|date=January 2020}}
[[File:
'''Object-oriented programming''' ('''OOP''') is a [[programming paradigm]] based on the
|year=2011
|title=Object-Oriented Simulation of systems with sophisticated control
|journal=International Journal of General Systems
|
|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
|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>
==History==
|last1=McCarthy
|first1=John
|author1-link=John McCarthy (computer scientist)
|last2=Abrahams
|first2=Paul W.
|last3=Edwards
|first3=Daniel J.
|last4=Hart
|first4=Swapnil D.
|last5=Levin
|first5=Michael I.
|year=1962
|url=https://archive.org/details/lisp15programmer00john/page/105
|title=LISP 1.5 Programmer's Manual
|publisher=[[MIT Press]]
|page=[https://archive.org/details/lisp15programmer00john/page/105 105]
|isbn=978-0-262-13011-0
|quote=Object – a synonym for atomic symbol
|df=dmy-all
}}</ref>
Another early
|author=[[Ivan E. Sutherland]]
|title=Sketchpad: a man-machine graphical communication system
Line 50 ⟶ 63:
|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
Line 61 ⟶ 74:
|doi=10.1145/960118.808391
|doi-access=free
}}
</ref><ref>
{{Cite web
</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>
Simula was used mainly by researchers involved with [[physical modelling]], like the movement of ships and their content through cargo ports.<ref name="auto"/> Simula is generally accepted as being the first language with the primary features and framework of an object-oriented language.<ref>{{cite journal |last1=Madsen |first1=Ole Lehrman |title=Kristen Nygaard |journal=A.M. Turing Award Laureates |url=https://amturing.acm.org/award_winners/nygaard_5916220.cfm |access-date=4 February 2025}}</ref>
{{Quote box
|quote
|author
|source
|width
}}
Influenced by
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 |
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
|title=The early history of Smalltalk
|author=[[Alan C. Kay]]
Line 98 ⟶ 107:
|pages=69–95
|date=March 1993
|doi=
|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 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.]]
In the
At [[ETH Zürich]], [[Niklaus Wirth]] and his colleagues
==Features==
{{Anchor|Object-oriented source code}}
{{See also|Comparison of programming languages (object-oriented programming)|List of object-oriented programming terms}}
===Encapsulation===
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===
[[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>
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"/>
[[SOLID]] includes the [[open/closed principle]], which says that classes and functions should be "open for extension, but closed for modification". [[Luca Cardelli]] has stated that OOP languages have "extremely poor modularity properties with respect to class extension and modification", and tend to be extremely complex.<ref name="badprop"/> The latter point is reiterated by [[Joe Armstrong (programmer)|Joe Armstrong]], the principal inventor of [[Erlang (programming language)|Erlang]], who is quoted as saying:<ref name="armstrongjoe">{{cite book |last1=Armstrong |first1=Joe |author1-link=Joe Armstrong (programmer) |editor1-last=Seibel |editor1-first=Peter |title=Coders at Work: Reflections on the Craft of Programming |url=http://www.codersatwork.com/ |publisher=Codersatwork.com |archive-url=https://web.archive.org/web/20100305165150/http://www.codersatwork.com/ |archive-date=5 March 2010 |access-date=13 November 2009}}</ref>
{{Blockquote|The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.}}
Leo Brodie says that information hiding can lead to [[duplicate code]],<ref>{{Cite book |last1=Brodie |first1=Leo |year=1984 |url=https://thinking-forth.sourceforge.net/thinking-forth-ans.pdf |title=Thinking Forth |pages=92–93 |access-date=4 May 2018}}</ref> which goes against the [[don't repeat yourself]] rule of software development.<ref>{{cite web |work=Category Extreme Programming |last1=Hunt |first1=Andrew |url=http://wiki.c2.com/?DontRepeatYourself |title=Don't Repeat Yourself |access-date=4 May 2018}}</ref>
===Composition===
Via [[object composition]], an object can contain other objects. For example, an {{code|Employee}} object might contain an {{code|Address}} object, along with other information like {{code|name}} and {{code|position}}. Composition is a "has-a" relationships, like "an employee has an address".
===Inheritance===
====
In [[class-based programming]], the most common type of OOP, an object is an instance of a class. The class defines the data (variables) and methods (logic). An object is created via the [[Constructor (object-oriented programming)|constructor]]. Elements of class may include:
* [[Class variable]]
* [[Instance variable]]
* [[Member variable]]
* Class
* Instance
An [[abstract class]] cannot be directly instantiated as an object. It is only used as a super-class.
Other classes are utility classes which contain only class variables and methods and are not meant to be instantiated or subclassed.{{sfn|Bloch|2018|loc=Chapter §2 Item 4 Enforce noninstantiability with a private constructor|p=19}}
====Prototype-based====
Instead of providing a class concept, in [[prototype-based programming]], an object is linked to another object, called its ''prototype'' or ''parent''. In Self, an object may have multiple or no parents,<ref>{{cite book |chapter=Classifying prototype-based programming languages|chapter-url=https://www.lirmm.fr/~dony/postscript/proto-book.pdf|first1=C|last1=Dony|first2=J|last2=Malenfant|first3=D|last3=Bardon|title=Prototype-based programming: concepts, languages and applications |date=1999 |publisher=Springer |___location=Singapore Berlin Heidelberg |isbn=9789814021258}}</ref> but in the most popular prototype-based language, [[JavaScript]], an object has exactly one prototype link, up to the base object whose prototype is null.
A prototype acts as a model for new objects. For example, if you have an object {{code|fruit}}, you can make two objects {{code|apple}} and {{code|orange}} that share traits of the {{code|fruit}} prototype. Prototype-based languages also allow objects to have their own unique properties, so the {{code|apple}} object might have an attribute {{code|sugar_content}}, while the {{code|orange}} or {{code|fruit}} objects do not.
====No inheritance====
Some languages, like [[Go (programming language)|Go]], don't support inheritance.<ref>{{Cite web |url=https://golang.org/doc/faq#Is_Go_an_object-oriented_language |title=Is Go an object-oriented language? |access-date=April 13, 2019 |quote=Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy.}}</ref> Instead, they encourage "[[composition over inheritance]]", where objects are built using smaller parts instead of parent-child relationships. For example, instead of inheriting from class Person, the Employee class could simply contain a Person object. This lets the Employee class control how much of Person it exposes to other parts of the program. [[Delegation (object-oriented programming)|Delegation]] is another language feature that can be used as an alternative to inheritance.
====Inheritance and behavioral subtyping====
People often think that if one class inherits from another, it means the subclass "[[is a]]" more specific version of the original class. This presumes the [[program semantics]] are that objects from the subclass can always replace objects from the original class without problems. This concept is known as [[behavioral subtyping]], more specifically the [[Liskov substitution principle]].
However, this is often not true, especially in programming languages that allow [[mutable]] objects, objects that change after they are created. In fact, [[subtype polymorphism]] as enforced by the [[type checker]] in OOP languages cannot guarantee behavioral subtyping in most if not all contexts. For example, the [[circle-ellipse problem]] is notoriously difficult to handle using OOP's concept of inheritance. Behavioral subtyping is undecidable in general, so it cannot be easily implemented by a compiler. Because of this, programmers must carefully design class hierarchies to avoid mistakes that the programming language itself cannot catch.
===Dynamic dispatch===
A method may be invoked via [[dynamic dispatch]] such that the method is selected at runtime instead of compile time. If the method choice depends on more than one type of object (such as other objects passed as parameters), it's called [[multiple dispatch]].
Dynamic dispatch works together with inheritance: if an object doesn't have the requested method, it looks up to its parent class ([[Delegation (object-oriented programming)|delegation]]), and continues up the chain to find a matching method.
===Message passing===
[[Message passing]] is when the method name and its inputs are sent like a message to the object for it to act on.
===Polymorphism===
[[Polymorphism (computer science)|Polymorphism]] refers to [[subtyping]] or subtype polymorphism, where a function can work with a specific [[Interface (object-oriented programming)|interface]] and thus manipulate entities of different classes in a uniform manner.<ref>{{cite web |url=http://www.stroustrup.com/glossary.html#Gpolymorphism |last1=Stroustrup |first1=Bjarne |author1-link=Bjarne Stroustrup |title=Bjarne Stroustrup's C++ Glossary |date=February 19, 2007 |quote=polymorphism – providing a single interface to entities of different types.}}</ref>
For example, imagine a program has two shapes: a circle and a square. Both come from a common class called "Shape." Each shape has its own way of drawing itself. With subtype polymorphism, the program doesn't need to know the type of each shape, and can simply call the "Draw" method for each shape. The programming language runtime will ensure the correct version of the "Draw" method runs for each shape. Because the details of each shape are handled inside their own classes, this makes the code simpler and more organized, enabling strong [[separation of concerns]].
===Open recursion===
An object's methods can access the object's data. Many programming languages use a special word, like [[this (computer programming)|{{code|this|C++}}]] or {{code|self|swift}}, to refer to the current object. In languages that support [[open recursion]], a method in an object can call other methods in the same object, including itself, using this special word. This allows a method in one class to call another method defined later in a subclass, a feature known as [[late binding]].
==Design patterns==
[[Design pattern (computer science)|Design patterns]] are common solutions to problems in software design. Some design patterns are especially useful for OOP, and design patterns are typically introduced in an OOP context.
===Object patterns===
The following are notable [[software design pattern]]s for OOP objects.<ref name="R.C.Martin">{{cite web |url=http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf |title=Design Principles and Design Patterns |
*[[Function object]]: Class with one main method that acts like an [[anonymous function]] (in C++, the function operator, {{code|operator()}})
*[[Immutable object]]: does not change state after creation
*[[First-class object]]: can be used without restriction
*[[Container object]]: contains other objects
*[[Factory object]]: creates other objects
*[[Metaobject]]: Used to create other objects (similar to a [[class (computer science)|class]], but an object)
*[[Prototype pattern|Prototype object]]: a specialized metaobject that creates new objects by copying itself
*[[Singleton pattern|Singleton object]]: only instance of its class for the lifetime of the program
*[[Filter object]]: receives a stream of data as its input and transforms it into the object's output
===Gang of Four design patterns===
{{Main|Design pattern (computer science)}}
''[[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.
These solutions, called "design patterns," are grouped into three types:
* ''[[Creational pattern]]s'' (5): [[Factory method pattern]], [[Abstract factory pattern]], [[Singleton pattern]], [[Builder pattern]], [[Prototype pattern]]
* ''[[Structural pattern]]s'' (7): [[Adapter pattern]], [[Bridge pattern]], [[Composite pattern]], [[Decorator pattern]], [[Facade pattern]], [[Flyweight pattern]], [[Proxy pattern]]
Line 281 ⟶ 229:
===Object-orientation and databases===
{{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]].
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.
Some databases, called [[object database]]s, are designed to work with OOP. However, they have not been as popular or successful as relational databases.
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>
===Responsibility- vs. data-driven design===
In [[
===SOLID and GRASP guidelines===
[[SOLID]] is a
* [[Single responsibility principle]]: A class should have only one reason to change.
* [[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>
* Creator Principle: allows classes create objects they closely use.
* 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==
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==
Some believe that OOP places too much focus on using objects rather than on [[algorithm]]s and [[data structure]]s.<ref name="stepanov"/><ref name="hickey"/> For example, programmer [[Rob Pike]] pointed out that OOP can make programmers think more about type hierarchy than composition.<ref name="RobPike">{{cite web |url=https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html |title=Less is exponentially more |last1=Pike |first1=Rob |date=25 June 2012 |access-date=1 October 2016}}</ref> He has called OOP "the [[Roman numerals]] of computing".<ref>{{cite mailing list |last1=Pike |first1=Rob |author1-link=Rob Pike |date=2 March 2004 |url=http://groups.google.com/group/comp.os.plan9/msg/006fec195aeeff15 |title=[9fans] Re: Threads: Sewing badges of honor onto a Kernel |access-date=17 November 2016 |mailing-list=comp.os.plan9}}</ref> [[Rich Hickey]], creator of [[Clojure]], described OOP as overly simplistic, especially when it comes to representing real-world things that change over time.<ref name="hickey">{{cite conference |last1=Hickey |first1=Rich |date=November 2009 |url=http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey |title=Are We There Yet? (keynote) |conference=JVM Languages Summit}}</ref> [[Alexander Stepanov]] said that OOP tries to fit everything into a single type, which can be limiting. He argued that sometimes we need multisorted algebras: families of interfaces that span multiple types, such as in [[generic programming]]. Stepanov also said that calling everything an "object" doesn't add much understanding.<ref name="stepanov">{{Cite web |last1=Stepanov |first1=Alexander |author1-link=Alexander Stepanov |year=2001–2008 |url=http://www.stlport.org/resources/StepanovUSA.html |title=STLport: An Interview with A. Stepanov |access-date=21 April 2010}}</ref>
OOP was created to make code easier to [[code reuse|reuse]] and [[software maintenance|maintain]].<ref name="realisticcodereuse">{{Cite web |last1=Ambler |first1=Scott |date=1 January 1998 |title=A Realistic Look at Object-Oriented Reuse |access-date=5 August 2025 |publisher=drdobbs.com |url=http://www.drdobbs.com/184415594}}</ref> However, it was not designed to clearly show the flow of a program's instructions. That was left to the compiler. As computers began using more parallel processing and multiple [[thread (computer science)|threads]], it became more important to understand and control how instructions flow. This is difficult to do with OOP.<ref name="flaws">{{Cite web |first1=Asaf |last1=Shelly |title=Flaws of Object Oriented Modeling |date=22 August 2008|access-date=4 July 2010 |publisher=Intel Software Network |url=http://software.intel.com/en-us/blogs/2008/08/22/flaws-of-object-oriented-modeling/}}</ref><ref name="multithreadingisaverb">{{Cite web |first1=Justin |last1=James |title=Multithreading is a verb not a noun |date=1 October 2007 |access-date=4 July 2010 |publisher=techrepublic.com |url=http://blogs.techrepublic.com.com/programming-and-development/?p=518 |archive-url=https://web.archive.org/web/20071010105117/http://blogs.techrepublic.com.com/programming-and-development/?p=518 |archive-date=10 October 2007 |url-status=dead |df=dmy-all}}</ref><ref name="multicore">{{Cite web |first1=Asaf |last1=Shelly |title=HOW TO: Multicore Programming (Multiprocessing) Visual C++ Class Design Guidelines, Member Functions |date=22 August 2008 |access-date=4 July 2010 |publisher=support.microsoft.com |url=http://support.microsoft.com/?scid=kb%3Ben-us%3B558117}}</ref><ref>{{cite web|url=http://existentialtype.wordpress.com/2011/04/17/some-advice-on-teaching-fp/|title=Some thoughts on teaching FP|author=Robert Harper |publisher=Existential Type Blog|access-date=5 December 2011|date=17 April 2011|author-link=Robert Harper (computer scientist)}}</ref>
Many popular programming languages, like C++, Java, and Python, use OOP. In the past, OOP was widely accepted,<ref>{{cite book |last1=Brucker |first1=Achim D. |last2=Wolff |first2=Burkhart |title=ECOOP 2008 – Object-Oriented Programming |chapter=Extensible Universes for Object-Oriented Data Models |series=Lecture Notes in Computer Science |date=2008 |volume=5142 |pages=438–462 |doi=10.1007/978-3-540-70592-5_19|isbn=978-3-540-70591-8 |quote=object-oriented programming is a widely accepted programming paradigm}}</ref> but recently, some programmers have criticized it and prefer functional programming instead.<ref>{{cite news |last1=Cassel |first1=David |title=Why Are So Many Developers Hating on Object-Oriented Programming? |url=https://thenewstack.io/why-are-so-many-developers-hating-on-object-oriented-programming/ |work=The New Stack |date=21 August 2019}}</ref> A study by Potok et al. found no major difference in productivity between OOP and other methods.<ref>{{Cite journal |url=http://www.csm.ornl.gov/~v8q/Homepage/Papers%20Old/spetep-%20printable.pdf |title=Productivity Analysis of Object-Oriented Software Developed in a Commercial Environment |last1=Potok |first1=Thomas |last2=Vouk |first2=Mladen |last3=Rindos |first3=Andy |journal=Software: Practice and Experience |volume=29|issue=10|pages=833–847 |year=1999 |access-date=21 April 2010 |doi=10.1002/(SICI)1097-024X(199908)29:10<833::AID-SPE258>3.0.CO;2-P |s2cid=57865731}}</ref>
[[Paul Graham (computer programmer)|Paul Graham]], a well-known computer scientist, believes big companies like OOP because it helps manage large teams of average programmers. He argues that OOP adds structure, making it harder for one person to make serious mistakes, but at the same time restrains smart programmers.<ref name="graham">{{Cite web |last1=Graham |first1=Paul |title=Why ARC isn't especially Object-Oriented. |url=http://www.paulgraham.com/noop.html |publisher=PaulGraham.com |access-date=13 November 2009 |author-link=Paul Graham (computer programmer)}}</ref> [[Eric S. Raymond]], a [[Unix]] programmer and [[open-source software]] advocate, argues that OOP is not the best way to write programs.<ref name="Eric S. Raymond 2003"/>
Richard Feldman says that, while OOP features helped some languages stay organized, their popularity comes from other reasons.<ref>{{cite web |last1=Feldman |first1=Richard |title=Why Isn't Functional Programming the Norm? |website=[[YouTube]] |date=30 September 2019 |url=https://www.youtube.com/watch?v=QyJZzq0v7Z4&t=2069s |language=en}}</ref> Lawrence Krubner argues that OOP doesn't offer special advantages compared to other styles, like functional programming, and can complicate coding.<ref name="lawrence">{{Cite web |last1=Krubner |first1=Lawrence |title=Object Oriented Programming is an expensive disaster which must end |url=http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end |publisher=smashcompany.com |access-date=14 October 2014 |archive-url=https://web.archive.org/web/20141014233854/http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end |archive-date=14 October 2014 |url-status=dead}}</ref> [[Luca Cardelli]] says that OOP is slower and takes longer to compile than procedural programming.<ref name="badprop">{{Cite journal |first1=Luca |last1=Cardelli|title=Bad Engineering Properties of Object-Oriented Languages |url=http://lucacardelli.name/Papers/BadPropertiesOfOO.html |year=1996 |access-date=21 April 2010 |doi=10.1145/242224.242415 |journal=ACM Comput. Surv. |volume=28 |issn=0360-0300 |pages=150–es |author-link=Luca Cardelli |issue=4es |s2cid=12105785 |url-access=subscription}}</ref>
==See also==
{{Portal|Computer programming}}
* [[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==
Line 361 ⟶ 296:
==Further reading==
* {{Cite book
|
|
|author-link=Martin Abadi
|author2=Luca Cardelli
Line 372 ⟶ 307:
}}
* {{Cite book
|
|
|author-link=Harold Abelson
|author2=Gerald Jay Sussman
Line 388 ⟶ 323:
}}
* {{Cite journal
|
|
|date=February 2006
|title
|journal
|volume
|issue
|pages
|issn
|doi
|s2cid
}}
*{{cite book
|
|
|
|
|
|
|
}}
* {{Cite book
|last1=Booch
|first1=Grady
|
|year=1997
|title=Object-Oriented Analysis and Design with Applications
Line 420 ⟶ 355:
}}
* {{Cite book
|
|
|author2=Oliver Sims
|year=1998
Line 431 ⟶ 366:
}}
* {{Cite book
|
|
|author-link=Erich Gamma
|author2=Richard Helm
Line 448 ⟶ 383:
}}
* {{Cite book
|
|
|author-link=Paul Harmon (management author)
|author2=William Morrissey
Line 459 ⟶ 394:
}}
* {{Cite book
|
|
|author-link=Ivar Jacobson
|year=1992
Line 470 ⟶ 405:
}}
* {{Cite book
|
|
|author-link
|title
|url
|access-date
|archive-url
|archive-date
|url-status
|df
}}
* {{Cite book
|
|
|author-link=Bertrand Meyer
|year=1997
Line 492 ⟶ 427:
}}
* {{Cite book
|
|
|year=2013
|title=OOP – Learn Object Oriented Thinking & Programming
Line 501 ⟶ 436:
}}
* {{Cite book
|last1=Rumbaugh
|first1=James
|
|last2=Blaha |first2=Michael
|
|last4=Eddy |first4=Frederick
|
|year=1991
|title=Object-Oriented Modeling and Design
Line 515 ⟶ 450:
}}
* {{Cite book
|
|
|year=2006
|title=Object-Oriented and Classical Software Engineering, Seventh Edition
Line 523 ⟶ 458:
}}
* {{Cite book
|
|
|year=1993
|title=Object oriented programming with ANSI-C
Line 531 ⟶ 466:
|hdl=1850/8544}}
* {{Cite book
|
|
|year=1992
|title=Object-Oriented Information Systems – Planning and Implementation
Line 540 ⟶ 475:
}}
* {{Cite book
|
|
|year=2009
|title=The Object-Oriented Thought Process, Third Edition
Line 548 ⟶ 483:
}}
* {{Cite book
|
|
|year=2004
|title=Object Thinking (Developer Reference)
Line 562 ⟶ 497:
* [http://www.codeproject.com/Articles/22769/Introduction-to-Object-Oriented-Programming-Concep Introduction to Object Oriented Programming Concepts (OOP) and More] by L.W.C. Nirosh
*[https://thenewstack.io/why-are-so-many-developers-hating-on-object-oriented-programming/ Discussion on Cons of OOP]
* [http://java.sun.com/docs/books/tutorial/java/concepts/
{{Programming paradigms navbox}}
{{Types of programming languages}}
{{Software engineering}}
{{Authority control}}
Line 572 ⟶ 507:
[[Category:Object-oriented programming| ]]
[[Category:Programming paradigms]]
<!-- Hidden categories below -->
[[Category:Articles with example code]]
| |||