Content deleted Content added
Line 17:
==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—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/|accessdate=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|accessdate=7 October 2012}}</ref> Now, a function that takes a 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 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.
| |||