Content deleted Content added
Change link to dynamic type in history section from "dynamic programming" to "dynamic type" in "type system" |
→Inheritance: add sub-sections |
||
Line 107:
===Inheritance===
OOP languages are diverse, but typically OOP languages allow [[Inheritance (object-oriented programming)|inheritance]] for code reuse and extensibility in the form of either [[class (computer science)|classes]] or [[Prototype-based programming|prototypes]]. These forms of inheritance are significantly different, but analogous terminology is used to define the concepts of ''object'' and ''instance''.
==== Class-based ====
In [[class-based programming]], the most popular style, each object is required to be an [[instance (computer science)|instance]] of a particular ''class''. The class defines the data format or [[data type|type]] (including member variables and their types) and available procedures (class methods or member functions) for a given type or class of object. Objects are created by calling a special type of method in the class known as a [[Constructor (object-oriented programming)|constructor]]. Classes may inherit from other classes, so they are arranged in a hierarchy that represents "is-a-type-of" relationships. For example, class Employee might inherit from class Person. All the data and methods available to the parent class also appear in the child class with the same names. For example, class Person might define variables "first_name" and "last_name" with method "make_full_name()". These will also be available in class Employee, which might add the variables "position" and "salary". It is guaranteed that all instances of class Employee will have the same variables, such as the name, position, and salary. Procedures and variables can be specific to either the class or the instance; this leads to the following terms:
Line 119 ⟶ 121:
[[Abstract class]]es cannot be instantiated into objects; they exist only for inheritance into other "concrete" classes that can be instantiated. In Java, the <code>[[final (Java)|final]]</code> keyword can be used to prevent a class from being subclassed.{{sfn|Bloch|2018|loc=Chapter §2 Item 4 Enforce noninstantiability with a private constructor|p=19}}
==== Prototype-based ====
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''.
==== Absence ====
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> 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. [[Delegation (object-oriented programming)|Delegation]] is another language feature that can be used as an alternative to inheritance.
[[Rob Pike]] 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> He 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>
[[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>
| |||