Object-oriented programming: Difference between revisions

Content deleted Content added
Inheritance: Edit for brevity
Use OOP
Line 96:
}}
 
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 object-oriented programmingOOP language. By 1967, Kay was already using the term "object-oriented programming" in conversation.<ref name=alanKayOnOO/> Although sometimes called the "father" of object-oriented programmingOOP,<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 object-oriented programmingOOP 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>
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 |last=Jones |first=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>
 
Line 112:
</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 |title=Thinglab--a constraint-oriented simulation laboratory. |date=1979 |url=https://constraints.cs.washington.edu/ui/thinglab-tr.pdf |publisher=Stanford University}}</ref>
 
In the late 1970s and 1980s, object-oriented programmingOOP rose to prominence. The [[Flavors (programming language)|Flavors]] object-oriented Lisp was developed starting 1979, introducing [[multiple inheritance]] and [[mixins]].<ref>{{cite conference |last1=Moon |first1=David A. |author-link1=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 beginning 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]].
 
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}}
 
In the 1990s, object-oriented programmingOOP 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 (programming language)|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 [[Mac OS X]] and written in [[Objective-C]]. OOP toolkits also enhanced the popularity of [[event-driven programming]].{{citation needed|date=February 2025}}
 
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.
Line 174:
===Data abstraction and encapsulation===
 
Data [[Abstraction (computer science)|abstraction]] is a way of organizing code so that only certain parts of the data are visible to related functions ([[data hiding]]). This helps prevent mistakes and makes the program easier to manage. Because data abstraction works well, many programming styles, like object-oriented programmingOOP and functional programming, use it as a key principle. [[Encapsulation (computer programming)|Encapsulation]] is another important idea in programming. It means keeping the internal details of an object hidden from the outside code. This makes it easier to change how an object works on the inside without affecting other parts of the program, such as in [[code refactoring]]. Encapsulation also helps keep related code together ([[Coupling (computer programming)|decoupling]]), making it easier for programmers to understand.
 
In object-oriented programmingOOP, objects act as a barrier between their internal workings and external code. Outside code can only interact with an object by calling specific ''public'' methods or variables. If a class only allows access to its data through methods and not directly, this is called [[information hiding]]. When designing a program, it's often recommended to keep data as hidden as possible. This means using local variables inside functions when possible, then private variables (which only the object can use), and finally public variables (which can be accessed by any part of the program) if necessary. Keeping data hidden helps prevent problems when changing the code later.<ref>{{Cite book |last=McDonough |first=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> Some programming languages, like Java, control information hiding by marking variables as <code>private</code> (hidden) or <code>public</code> (accessible).{{sfn|Bloch|2018|loc=Chapter §4 Item15 Minimize the accessibility of classes and members|pp=73-77}} Other languages, like Python, rely on naming conventions, such as starting a private method's name with an underscore. Intermediate levels of access also exist, such as Java's <code>protected</code> keyword, (which allows access from the same class and its subclasses, but not objects of a different class), and the <code>internal</code> 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>
 
Abstraction and information hiding are important concepts in programming, especially in object-oriented languages.<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> Programs often create many copies of objects, and each one works independently. Supporters of this approach say it makes code easier to reuse and intuitively represents real-world situations.<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> However, others argue that object-oriented programmingOOP does not enhance readability or modularity.<ref name="badprop"/><ref name="armstrongjoe"/> [[Eric S. Raymond]] has written that object-oriented programmingOOP 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]].<ref name="Eric S. Raymond 2003"/>
 
One programming principle, called the "[[open/closed principle]]", 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 (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>
Line 187:
 
===Polymorphism===
[[Polymorphism (computer science)|Polymorphism]] is the use of one symbol to represent multiple different types.<ref name="Luca">{{Cite journal |last1=Cardelli |first1=Luca |author1-link=Luca Cardelli |last2=Wegner |first2=Peter |author2-link=Peter Wegner (computer scientist)|doi=10.1145/6041.6042 |title=On understanding types, data abstraction, and polymorphism |journal=[[ACM Computing Surveys]] |volume=17 |issue=4 |pages=471–523 |date=December 1985 |url=http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf |citeseerx=10.1.1.117.695 |s2cid=2921816}}: "Polymorphic types are types whose operations are applicable to values of more than one type."</ref> In object-oriented programmingOOP, polymorphism more specifically 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]].
Line 193:
===Open recursion===
 
In object-oriented programmingOOP, objects have methods that can change or use 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]].
 
=={{Anchor|Object-oriented source code}}OOP languages==
Line 211:
[[File:Tiobeindex.png|thumb|350px|The [[TIOBE index|TIOBE]] programming language popularity index graph from 2002 to 2023. In the 2000s the object-oriented [[Java (programming language)|Java]] (orange) and the [[Procedural programming|procedural]] [[C (programming language)|C]] (dark blue) competed for the top position.]]
 
Many popular programming languages, like C++, Java, and Python, use object-oriented programmingOOP. 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| 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>
 
[[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| 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, argues that OOP is not the best way to write programs.<ref name="Eric S. Raymond 2003"/>
Line 218:
 
===OOP in dynamic languages===
In recent years, object-oriented programming (OOP) has become very popular in [[dynamic programming language]]s. Some languages, like [[Python (programming language)|Python]], [[PowerShell]], [[Ruby (programming language)|Ruby]] and [[Groovy (programming language)|Groovy]], were designed with OOP in mind. Others, like [[Perl]], [[PHP]], and [[ColdFusion]], started as non-OOP languages but added OOP features later (starting with Perl 5, PHP 4, and ColdFusion version 6).
 
On the web, [[HTML]], [[XHTML]], and [[XML]] documents use the [[Document Object Model]] (DOM), which works with the [[JavaScript]] language. JavaScript is a well-known example of a [[prototype-based programming|prototype-based]] language. Instead of using classes like other OOP languages, JavaScript creates new objects by copying (or "cloning") existing ones. Another language that uses this method is [[Lua (programming language)|Lua]].
Line 234:
 
==Design patterns==
[[Design pattern (computer science)|Design patterns]] are common solutions to problems in software design. Some design patterns are especially useful for object-oriented programmingOOP, and design patterns are typically introduced in an OOP context.
 
===Object patterns===
Line 255:
{{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 object-oriented programmingOOP and explains 23 common ways to solve programming problems.
 
These solutions, called "design patterns," are grouped into three types:
Line 266:
{{Main|Object-relational impedance mismatch|Object-relational mapping|Object database}}
 
Both object-oriented programmingOOP 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| first = Ted| last = Neward| title = The Vietnam of Computer Science| date = 26 June 2006| 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 object-oriented programmingOOP. 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>
Line 299:
{{see also|Formal semantics of programming languages}}
 
In object-oriented programmingOOP, objects are things that exist while a program is running. An object can represent anything, like a person, a place, a bank account, or a table of data. Many researchers have tried to formally define how OOP works. [[Record (computer science)|Records]] are the basis for understanding objects. They can represent fields, and also methods, if [[function literal]]s can be stored. However, [[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|last=Poll|first=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| first=Martin| last=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 |title=Tai-e: A Developer-Friendly Static Analysis Framework for Java by Harnessing the Good Designs of Classics|conference=ISSTA 2023 |date=12 July 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 |title=Analysing the Analysers: An Investigation of Source Code Analysis Tools |journal=Applied Computer Systems |date=1 June 2024 |volume=29 |issue=1 |pages=98–111 |doi=10.2478/acss-2024-0013}}</ref>
 
==See also==