In knowledge representation and ontology components, including for object-oriented programming and design, is-a (also written as is_a or is a) is a subsumptive 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.[1]
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.
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:
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.
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 B : public A
void UseAnA(A const& some_A)
void SomeFunc[3]
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 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.[4]
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:
The following parameterizations of PayloadList are subtypes of :
See 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,".[5] Following example shows a violation of LSP.
Here is perhaps an example of violation of LSP:
However, this violates LSP even though the is-a relationship 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.
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.