SUPPORT THE WORK

GetWiki

is-a

ARTICLE SUBJECTS
aesthetics  →
being  →
complexity  →
database  →
enterprise  →
ethics  →
fiction  →
history  →
internet  →
knowledge  →
language  →
licensing  →
linux  →
logic  →
method  →
news  →
perception  →
philosophy  →
policy  →
purpose  →
religion  →
science  →
sociology  →
software  →
truth  →
unix  →
wiki  →
ARTICLE TYPES
essay  →
feed  →
help  →
system  →
wiki  →
ARTICLE ORIGINS
critical  →
discussion  →
forked  →
imported  →
original  →
is-a
[ temporary import ]
please note:
- the content below is remote from Wikipedia
- it has been imported raw for GetWiki
{{multiple issues|{{Inappropriate person|date=August 2018}}{{essay-like|date=August 2018}}{{technical|date=August 2018}}{{too few opinions|date=August 2018}}{{weasel|date=August 2018}}{{Rewrite|date=August 2018}}}}In knowledge representation, object-oriented programming and design (see object-oriented program architecture), is-a (is_a or is a) is a (wikt:subsume|subsumption)See Liskov substitution principle. relationship between abstractions (e.g. types, classes), wherein one class A is a subclass of another class B (and so B is a superclass of A).In other words, type A is a subtype of type B when A’s specification implies B’s specification. That is, any object (or class) that satisfies A’s specification also satisfies B’s specification, because B’s specification is weaker.WEB, Subtypes and Subclasses,weblink MIT OCW, 2 October 2012, The is-a relationship is to be contrasted with the has-a (has_a or has a) relationship between types (classes); confusing the relations has-a and is-a is a common error when designing a model (e.g., a computer program) of the real-world relationship between an object and its subordinate. The is-a relationship may also be contrasted with the instance-of relationship between objects (instances) and types (classes): see "type-token distinction" and "type-token relations."Type–token relationsTo summarize the relations, we have
  • hyperonym–hyponym (supertype–subtype) relations between types (classes) defining a taxonomic hierarchy, where
    • for a subsumption relation: a hyponym (subtype, subclass) has a type-of (is-a) relationship with its hyperonym (supertype, superclass);
  • holonym–meronym (whole/entity/container-part/constituent/member) relations between types (classes) defining a possessive hierarchy, where
  • concept-object (type-token) relations between types (classes) and objects (instances), where
    • a token (object) has an instance-of relationship with its type (class).

Examples of subtyping

Subtyping enables a given type to be substituted for another type or abstraction. Subtyping is said to establish an is-a relationship between the subtype and some existing abstraction, either implicitly or explicitly, depending on language support. The relationship can be expressed explicitly via inheritance in languages that support inheritance as a subtyping mechanism.

C++

The following C++ code establishes an explicit inheritance relationship between classes B and A, where B is both a subclass and a subtype of A, and can be used as an A wherever a B is specified (via a reference, a pointer or the object itself).class A{ public:
void DoSomethingALike() const {}
};class B : public A{ public:
void DoSomethingBLike() const {}
};void UseAnA(A const& some_A){
some_A.DoSomethingALike();
}void SomeFunc(){
B b;
UseAnA(b); // b can be substituted for an A.
}BOOK
, Mitchell
, John
, John C. Mitchell
, Concepts in programming language
, 2002
, Cambridge University Press
, Cambridge, UK
, 0-521-78098-5
, 287
, 10 "Concepts in object-oriented languages",

Python

The following python code establishes an explicit inheritance relationship between classes B and A, where B is both a subclass and a subtype of A, and can be used as an A wherever a B is required.class A:
def doSomethingALike(self):
pass
class B(A):
def doSomethingBLike(self):
pass
def useAnA(some_A):
some_A.doSomethingALike()
def someFunc():
b = B()
useAnA(b) # b can be substituted for an A.
The following example, type(a) is a "regular" type, and type(type(a)) is a metatype. While as distributed all types have the same metatype (PyType_Type, which is also its own metatype), this is not a requirement. The type of classic classes, known as types.ClassType, can also be considered a distinct metatype.WEB, Guido van Rossum, Subtyping Built-in Types,weblink 2 October 2012,
a = 0 type(a)
type(type(a))
type(type(type(a)))
type(type(type(type(a))))

Java

In Java, is-a relation between the type parameters of one class or interface and the type parameters of another are determined by the extends and implements clauses.Using the Collections classes, ArrayList implements List, and List extends Collection. So ArrayList is a subtype of List, which is a subtype of Collection. The subtyping relationship is preserved between the types automatically. When we define an interface, PayloadList, that associates an optional value of generic type P with each element. Its declaration might look like:interface PayloadList extends List {
void setPayload(int index, P val);
...
}The following parameterizations of PayloadList are subtypes of List:PayloadListPayloadListPayloadList

Liskov substitution principle

Liskov substitution principle explains a property, "If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T,".BOOK, Liskov, Barbara, Data Abstraction and Hierarchy, May 1988, SIGPLAN Notices, Following example shows a violation of LSP.void DrawShape(const Shape& s){
if (typeid(s) == typeid(Square))
DrawSquare(static_cast(s));
else if (typeid(s) == typeid(Circle))
DrawCircle(static_cast(s));
}Obviously, the DrawShape function is badly formatted. It has to know about every derivative classes of Shape class. Also, it should be changed whenever new subclass of Shape are created. In object-oriented design, many{{who|date=April 2017}} view the structure of this as anathema.Here is a more subtle example of violation of LSP:class Rectangle{
public:
void SetWidth(double w) { itsWidth = w; }
void SetHeight(double h) { itsHeight = h; }
double GetHeight() const { return itsHeight; }
double GetWidth() const { return itsWidth; }
private:
double itsWidth;
double itsHeight;
};This works well but when it comes to Square class, which inherits Rectangle class, it violates LSP even though the is-a relationship holds between Rectangle and Square. Because square is rectangular. The following example overrides two functions, Setwidth and SetHeight, to fix the problem. But fixing the code implies that the design is faulty.public class Square : Rectangle{
public:
virtual void SetWidth(double w);
virtual void SetHeight(double h);
};void Square::SetWidth(double w){
Rectangle::SetWidth(w);
Rectangle::SetHeight(w);
}void Square::SetHeight(double h){
Rectangle::SetHeight(h);
Rectangle::SetWidth(h);
}The following example, function g just works for Rectangle class but not for Square, and so the open-closed principle has been violated.void g(Rectangle& r){
r.SetWidth(5);
r.SetHeight(4);
assert(r.GetWidth() * r.GetHeight()) == 20);
}WEB, The Liskov Substitution Principle,weblink Robert C. Martin, 1996, 2 October 2012, yes,weblink" title="web.archive.org/web/20150905081111weblink">weblink 5 September 2015,

See also

Notes

{{reflist|30em}}

References



- content above as imported from Wikipedia
- "is-a" does not exist on GetWiki (yet)
- time: 3:18pm EDT - Mon, Sep 24 2018
[ this remote article is provided by Wikipedia ]
LATEST EDITS [ see all ]
GETWIKI 09 MAY 2016
GETWIKI 18 OCT 2015
M.R.M. Parrott
Biographies
GETWIKI 20 AUG 2014
GETWIKI 19 AUG 2014
GETWIKI 18 AUG 2014
Wikinfo
Culture
CONNECT