Class-based programming: Difference between revisions

Revision as of 08:06, 1 June 2018

Revision as of 08:16, 1 October 2018

Line 2:

{{Programming paradigms}}

'''Class-based programming''', or more commonly '''class-orientation''', is a style of [[objectObject-oriented programming]] (OOP) in which inheritance isoccurs achieved byvia defining ''[[classClass (computer scienceprogramming)|classes]]'' of [[objectObject (computer science)|objects]], asinstead of inheritance opposedoccurring tovia the objects themselvesalone (compare [[prototype-based programming]]).

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 [[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 thatthe 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|date=|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|accessdate=11 December 2017|language=en}}</ref>

|width = 50%

|align = left

}}

Line 33:

:''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'''. }}''

-->

ThereforeThus, 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 [[Invariant (computer science)|invariants]] 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.