Is-a

In knowledge representation, object-oriented programming and design (see object-oriented program architecture), is-a (is_a or is a) is a subsumption 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.

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.

To summarize the relations, there are:

* hyperonym–hyponym (supertype/superclass–subtype/subclass) 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
** for an aggregation (i.e. without ownership) relation:
*** a holonym (whole) has a ''has-a'' relationship with its meronym (part),
** for a composition (i.e. with ownership) relation:
*** a meronym (constituent) has a ''part-of'' relationship with its holonym (entity),
** for a containment relation:
*** a meronym (member) has a ''member-of'' relationship with its holonym (container);
* 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
;

class B : public A
;

void UseAnA(A const& some_A)

void SomeFunc()

Python

The following python code establishes an explicit inheritance relationship between classes and , where is both a subclass and a subtype of , and can be used as an wherever a is required.

class A:
def do_something_a_like(self):
pass

class B(A):
def do_something_b_like(self):
pass

def use_an_a(some_a):
some_a.do_something_a_like()

def some_func():
b = B()
use_an_a(b) # b can be substituted for an A.

The following example, is a "regular" type, and is a metatype. While as distributed all types have the same metatype (, which is also its own metatype), this is not a requirement. The type of classic classes, known as , can also be considered a distinct metatype.

>>> 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 classes, implements , and extends . So is a subtype of , which is a subtype of . The subtyping relationship is preserved between the types automatically. When defining an interface, , that associates an optional value of generic type P with each element, its declaration might look like:

interface PayloadList extends List

The following parameterizations of PayloadList are subtypes of :

PayloadList
PayloadList
PayloadList

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,"''. Following example shows a violation of LSP.

void DrawShape(const Shape& 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 view the structure of this as anathema.

Here is a more subtle example of violation of LSP:

class Rectangle
;

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
;
void Square::SetWidth(double w)

void Square::SetHeight(double 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)

See also

* Inheritance (object-oriented programming)
* Liskov substitution principle (in object-oriented programming)
* Subsumption
* Is-a
** Hypernymy (and supertype)
** Hyponymy (and subtype)
* Has-a
** Holonymy
** Meronymy

Notes

{{reflist, 30em

References

* Ronald J. Brachman
What IS-A is and isn't. An Analysis of Taxonomic Links in Semantic Networks
IEEE Computer, 16 (10); October 1983
* Jean-Luc Hainaut, Jean-Marc Hick, Vincent Englebert, Jean Henrard, Didier Roland

ER 1996: 42-57

Object-oriented programming
Knowledge representation
Abstraction
Articles with example Java code