Class-based programming: Difference between revisions

Revision as of 12:47, 2 February 2021

Latest revision as of 22:18, 1 February 2024

(5 intermediate revisions by 5 users not shown)

Line 1:

{{Short description|Style of object-oriented programming where inheritance is based on classes}}

{{Refimprove|date=February 2013}}

{{Programming paradigms}}

'''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, instead of 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 [[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., objects of the class) in the class hierarchy (essential for runtime inheritance features).

{{Quote box

|quote = Object-oriented programming is more than just classes and objects; it's a whole programming paradigm based around ''objects'' (data structures) that contain data fields and methods. It is essential to understand this; using classes to organize a bunch of unrelated methods together is not object orientation.

|author = Junade Ali

|source = ''Mastering PHP Design Patterns''<ref>{{cite book|last1=Ali|first1=Junade|title=Mastering PHP Design Patterns {{!}} PACKT Books|publisher=Packt Publishing Limited|___location=Birmingham, England, UK|isbn=978-1-78588-713-0|page=11|edition=1|url=https://www.packtpub.com/application-development/mastering-php-design-patterns|access-date=11 December 2017|language=en}}</ref>

|width = 50%

|align = left

}}

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

Line 24 ⟶ 16:

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

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. The critics say one might create a bag class that stores a [[Collection class|collection]] of objects, then extend 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 an 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. [[Barbara Liskov]] and [[Jeannette Wing]] formulated the principle succinctly in a 1994 paper as follows:

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

Line 49 ⟶ 41:

{{Reflist}}

{{Programming languageparadigms navbox}}

{{Types of programming languages}}

{{DEFAULTSORT:Class-Based Programming}}