Is-a

Inknowledge representationandontology components,including forobject-oriented programminganddesign,is-a(also written asis_aoris a) is asubsumptiverelationship betweenabstractions(e.g.,types,classes), wherein oneclassAis asubclassof another classB(and soBis asuperclassofA). In other words, type A is asubtypeof type B when A'sspecificationimplies 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.

For example, a cat 'is a' animal, but not vice versa. All cats are animals, but not all animals are cats. Behaviour that is relevant to all animals is defined on an animal class, whereas behaviour that is relevant only for cats is defined in a cat class. By defining the cat class as 'extending' the animal class, all cats 'inherit' the behaviour defined for animals, without the need to explicitly code that behaviour for cats.

Related concepts

Theis-arelationship is to be contrasted with thehas-a(has_aorhas a) relationship between types (classes); confusing the relationshas-aandis-ais a common error when designing a model (e.g., acomputer program) of the real-world relationship between an object and its subordinate. Theis-arelationship may also be contrasted with theinstance-ofrelationship between objects (instances) and types (classes): seeType–token distinction.

To summarize the relations, there are:

• hyperonym–hyponym(supertype/superclass–subtype/subclass) relations between types (classes) defining a taxonomic hierarchy, where
  • for asubsumptionrelation: a hyponym (subtype, subclass) has atype-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 anaggregation(i.e. without ownership) relation:
    • a holonym (whole) has ahas-arelationship with its meronym (part),
  • for acomposition(i.e. with ownership) relation:
    • a meronym (constituent) has apart-ofrelationship with its holonym (entity),
  • for acontainmentrelation:
    • a meronym (member) has amember-ofrelationship with its holonym (container);
• concept–object (type–token) relations between types (classes) and objects (instances), where
  • a token (object) has aninstance-ofrelationship with its type (class).

Examples of subtyping

Subtypingenables a given type to be substituted for another type or abstraction. Subtyping is said to establish anis-arelationship 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 classesBandA,whereBis both a subclass and a subtype ofA,and can be used as anAwherever aBis specified (via a reference, a pointer or the object itself).

classA
{public:
voidDoSomethingALike()const{}
};

classB:publicA
{public:
voidDoSomethingBLike()const{}
};

voidUseAnA(Aconst&some_A)
{
some_A.DoSomethingALike();
}

voidSomeFunc()
{
Bb;
UseAnA(b);// b can be substituted for an A.
}

Python

The following Python code establishes an explicit inheritance relationship between classesBandA,whereBis both a subclass and a subtype ofA,and can be used as anAwherever aBis required.

classA:
defdo_something_a_like(self):
pass

classB(A):
defdo_something_b_like(self):
pass

defuse_an_a(some_a):
some_a.do_something_a_like()

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

The following example,type(a)is a "regular" type, andtype(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 astypes.ClassType,can also be considered a distinct metatype.

>>>a=0
>>>type(a)
<type 'int'>
>>>type(type(a))
<type 'type'>
>>>type(type(type(a)))
<type 'type'>
>>>type(type(type(type(a))))
<type 'type'>

Java

In Java,is-arelation between the type parameters of one class or interface and the type parameters of another are determined by the extends andimplementsclauses.

Using theCollectionsclasses,ArrayList<E>implementsList<E>,andList<E>extendsCollection<E>.SoArrayList<String>is a subtype ofList<String>,which is a subtype ofCollection<String>.The subtyping relationship is preserved between the types automatically. When defining an interface,PayloadList,that associates an optional value ofgeneric typeP with each element, its declaration might look like:

interfacePayloadList<E,P>extendsList<E>{
voidsetPayload(intindex,Pval);
...
}

The following parameterizations of PayloadList are subtypes ofList<String>:

PayloadList<String,String>
PayloadList<String,Integer>
PayloadList<String,Exception>

Liskov substitution principle

Main article: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.

Here is perhaps an example of violation of LSP:

classRectangle
{
public:
voidSetWidth(doublew){itsWidth=w;}
voidSetHeight(doubleh){itsHeight=h;}
doubleGetHeight()const{returnitsHeight;}
doubleGetWidth()const{returnitsWidth;}
doubleGetArea()const{returnGetHeight()*GetWidth();}
private:
doubleitsWidth;
doubleitsHeight;
};

From a programing point of view, the Square class may be implemented by inheriting from the Rectangle class.

publicclassSquare:Rectangle
{
public:
virtualvoidSetWidth(doublew);
virtualvoidSetHeight(doubleh);
};
voidSquare::SetWidth(doublew)
{
Rectangle::SetWidth(w);
Rectangle::SetHeight(w);
}
voidSquare::SetHeight(doubleh)
{
Rectangle::SetHeight(h);
Rectangle::SetWidth(h);
}

However, this violates LSP even though theis-arelationship holds between Rectangle and Square

Consider the following example, where function g does not work if a Square is passed in, and so the open-closed principle might be considered to have been violated.

voidg(Rectangle&r)
{
r.SetWidth(5);
r.SetHeight(4);
assert(r.GetArea())==20);// assertion will fail
}

Conversely, if one considers that the type of a shape should only be a constraint on the relationship of its dimensions, then it is the assumption in g() that SetHeight will change height, and area, but not width that is invalid, not just for true squares, but even potentially for other rectangles that might be coded so as to preserve area or aspect ratio when height changes.

See also

• Inheritance (object-oriented programming)
• Liskov substitution principle(inobject-oriented programming)
• Subsumption
• Is-a
  • Hypernymy(andsupertype)
  • Hyponymy(andsubtype)
• Has-a
  • Holonymy
  • Meronymy

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:Understanding Implementations of IS-A Relations.ER 1996: 42-57