Class-based programming: Difference between revisions

Revision as of 02:43, 24 December 2006

Latest revision as of 22:18, 1 February 2024

(77 intermediate revisions by 62 users not shown)

Line 1:

'''Class-based programming''', or more commonly '''class-orientation''', refers to the{{Short styledescription|Style of [[object-oriented programming]] in whichwhere inheritance is achievedbased byon defining ''classes'' of objects, as opposed to the objects themselves (compare [[Prototype-based programming]]).}}

{{Refimprove|date=February 2013}}

'''Class-based programming''', or more commonly '''class-orientation''', is a style of [[object-oriented programming]] (OOP) in which [[inheritance (object-oriented programming)|inheritance]] occurs via defining ''[[class (computer programming)|class]]es'' of [[object (computer science)|object]]s, instead of inheritance occurring via the objects alone (compare [[prototype-based programming]]).

The most popular and developed model of OOP is a class-based model, as opposed to an object-based model. In this model, objects are entities that combine ''[[state]]'' (i.e., data), ''[[behavior]]'' (i.e., procedures, or ''[[method (computer science)|method]]s'') and ''[[identity (object-oriented programming)|identity]]'' (unique existence among all other objects). The structure and behavior of an object are defined by a [[class (object-oriented programming)|class]], which is a [[definition]], or [[blueprint]], of all objects of a specific type. An object must be explicitly created based on a class and an object thus created is considered to be an [[instance]] of that class. An object is similar to a [[Data structure|structure]], with the addition of method pointers, member access control, and an implicit data member which locates instances of the class (i.e. actual objects of that class) in the class hierarchy (essential for runtime inheritance features).

The most popular and developed model of OOP is a class-based model, asinstead opposed toof an object-based model. In this model, objects are entities that combine ''[[state (computer science)|state]]'' (i.e., data), ''[[behavior]]'' (i.e., procedures, or ''[[method (computer science)|method]]s'') and ''[[identity (object-oriented programming)|identity]]'' (unique existence among all other objects). The structure and behavior of an object are defined by a [[class (object-oriented programming)|class]], which is a [[definition]], or [[blueprint]], of all objects of a specific type. An object must be explicitly created based on a class and an object thus created is considered to be an [[instantiation (computer science)|instance]] of that class. An object is similar to a [[Datadata structure|structure]], with the addition of method pointers, member access control, and an implicit data member which locates instances of the class (i.e. actual, objects of thatthe class) in the class hierarchy (essential for runtime inheritance features).

===Encapsulation===

===Encapsulation===

[[Information hiding|Encapsulation]] prevents users from breaking the [[Invariant (computer science)|invariants]] of the class, which is useful because it allows the implementation of a class of objects to be changed for aspects not exposed in the interface without impact to user code. The definitions of encapsulation focus on the grouping and packaging of related information ([[cohesion (computer science)|cohesion]]) rather than security issues. OOP languages do not normally offer formal security restrictions to the internal object state. Using a method of access is a matter of convention for the interface design.

=== Inheritance ===

:''See [[{{Main|Inheritance (object-oriented programming)|l1=Inheritance]], (also [[inheritance (computer science)]] for more)''}}

In class-based programming, [[inheritance (object-oriented programming)|inheritance]] is done by defining new classes as [[Extension (semantics)|extensions]] of existing classes: the existing class is the [[parent class]] and the new class is the [[Subclass (computer science)|child class]]. If a child class has only one parent class, this is known as ''[[single inheritance]],'' while if a child class can have more than one parent class, this is known as ''[[multiple inheritance]].'' This organizes classes into a [[hierarchy]], either a ''[[Tree (set theory)|tree]]'' (if single inheritance) or ''[[Lattice (order)|lattice]]'' (if multiple inheritance).

[[Inheritance (computer science)|Inheritance]] is typically done by grouping objects into ''classes'', and defining [[class (computer science)|class]]es as [[extension]]s of existing classes, and thus grouping classes into ''trees'' or ''lattices'' reflecting behavioral commonality. Although the use of classes is the most popular technique for inheritance, another well-known technique is [[Prototype-based programming]].

The defining feature of inheritance is that both interface and implementation are inherited; if only interface is inherited, this is known as [[interface inheritance]] or ''subtyping.'' Inheritance can also be done without classes, as in [[prototype-based programming]].

=== Critique of class-based models ===

==Critique==

Class-based languages, or, to be more precise, [[typed language]]s, where [[Subclass (computer science)|subclassing]] is the only way of [[subtyping]], have been criticized for mixing up implementations and interfaces&mdash;the essential principle in object-oriented programming. ItThe critics sayssay one might create a bag class that stores a [[Collection class|collection]] of objects, then extendsextend it to make a new class called a set class where the duplication of objects is eliminated.<ref>{{cite web|first=Oleg|last=Kiselyov|title=Subtyping, Subclassing, and Trouble with OOP|url=http://okmij.org/ftp/Computation/Subtyping/|access-date=7 October 2012}}</ref><ref>{{cite web|title=A set cannot be a subtype of a bag|last=Ducasse|first=Stéphane|url=http://stephane.ducasse.free.fr/Resources/LecturesInPowerpoint/STOOP-416-LSP.ppt|access-date=7 October 2012}}</ref> Now, a function that takes aan object of the bag class may expect that adding two objects increases the size of a bag by two, yet if one passes an object of a set class, then adding two objects may or may not increase the size of a bag by two. The problem arises precisely because subclassing implies subtyping even in the instances where the principle of subtyping, known as the [[Liskov substitution principle]], does not hold. Therefore[[Barbara normally one must distinguish subtypingLiskov]] and subclassing.[[Jeannette MostWing]] currentformulated object-orientedthe languagesprinciple distinguishsuccinctly subtypingin anda subclassing,1994 howeverpaper someas approaches to design do not.follows:

<!-- inline math as LaTeX has poor baseline alignment (better with MathJaX HTML/CSS rendering of LaTeX)

:''Let <math>q(x)</math> be a property provable about objects <math>x</math> of type <math>T</math>. Then <math>q(y)</math> should be provable for objects <math>y</math> of type <math>S</math>, where <math>S</math> is a subtype of <math>T</math>.''

--><!-- inline math as HTML -->

<blockquote>''Subtype Requirement'': Let {{tmath| \phi(x) }} be a property provable about objects {{tmath| x }} of type {{tmath| T}}. Then {{tmath| \phi(y) }} should be true for objects {{tmath| y }} of type {{tmath| S }} where {{tmath| S }} is a subtype of {{tmath| T}}. </blockquote>

<!-- inline math as HTML bold

:''Let {{math| '''q(x)''' }} be a property provable about objects {{math| '''x''' }} of type {{math| '''T'''. }} Then {{math| '''q(y)''' }} should be provable for objects {{math| '''y''' }} of type {{math| '''S''', }} where {{math| '''S''' }} is a subtype of {{math| '''T'''. }}''

-->

Thus, normally one must distinguish subtyping and subclassing. Most current object-oriented languages distinguish subtyping and subclassing, however some approaches to design do not.

Also, another common example is that a person object created from a [[Subclass (computer science)|child class]] cannot become an object of [[parent class]] because a child class and a parent class inherit a person class but class-based languages mostly do not allow to change the kind of class of the object at runtime. For class-based languages, this restriction is essential in order to preserve unified view of the class to its users. The users should not need to care whether one of the implementations of a method happens to cause changes that break the [[invariantInvariant (computer science)|invariants]]s of the class. Such changes can be made by destroying the object and constructing another in its place. Polymorphism can be used to preserve the relevant interfaces even when such changes are done, because the objects are viewed as black box abstractions and accessed via object [[identity (object-oriented programming)|identity]]. However, usually the value of object references referring to the object is changed, which causes effects to client code.

==Example languages==

[[:{{Category: see also|Class-based programming languages]] provides an exhaustive list.}}

Although [[Simula (programming language)|Simula]] introduced the class abstraction, the canonical example of a class-based language is [[Smalltalk programming language|Smalltalk]]. Others include [[PHP]], [[C++]], [[Java (programming language)|Java]] and, [[C Sharp (programming language)|C#]], and [[Objective-C]].

[[:Category:Class-based programming languages]] provides an exhaustive list.

==See also==

*[[Prototype-based programming]] (contrast)

*[[Programming paradigm]]s

*[[classClass (computer scienceprogramming)]]

==References==

[[Category:Object-oriented programming]]

{{Reflist}}

[[Category:Programming paradigms]]

[[Category:{{Programming paradigms]] navbox}}

[[ja:クラスベース]]

{{Types of programming languages}}

{{DEFAULTSORT:Class-Based Programming}}

[[Category:Object-oriented programming]]