Object-oriented programming: Difference between revisions

Revision as of 04:22, 29 July 2025

Revision as of 04:47, 29 July 2025

Line 127:

===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) holdscontains 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 {{endash}} allowing for changing how an object works without affecting its interface and therefore other code. Hidding information helps prevent problems when changing the code.<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> Objects act as a barrier between their internal workings and external, consuming code. Consuming code can only interact with an object via its public members.

In OOP, 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, controlprovide information hiding byvia markingvisibility variableskey aswords (<code>private</code> (hidden) orand <code>public</code> (accessible).{{sfn|Bloch|2018|loc=Chapter §4 Item15 Minimize the accessibility of classes and members|pp=73-77}} OtherSome languages, likedon't provide a visibility Pythonfeature, relybut ondevelopers namingmight conventions,follow a convention such as starting a private method'smember 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>

AbstractionSupporters andof information hiding areand importantdata conceptsabstraction insay programming,it especiallymakes incode objecteasier to reuse and intuitively represents real-orientedworld languagessituations.<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 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|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[[SOLID]] programming principle, calledincludes 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 (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>

{{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 copying the same code in multiple places ([[duplicate code|duplicating 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> which goes against the [[don't repeat yourself]] rule of software development.<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>

===Composition===

Line 173 ⟶ 186:

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

===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 OOP 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 OOP, 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 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|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>

{{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 copying the same code in multiple places ([[duplicate code|duplicating 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> which goes against the [[don't repeat yourself]] rule of software development.<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>

===Polymorphism===