is-a

<h2 id="related-concepts">Related concepts</h2>
<p>The <i>is-a</i> relationship is to be contrasted with the <i><a href="/facts/Has-a/lyFhMcdw">has-a</a></i> (<i>has_a</i> or <i>has a</i>) relationship between types (classes); confusing the relations <i>has-a</i> and <i>is-a</i> is a common error when designing a model (e.g., a <a href="/facts/Computer_program/e38jH9N9">computer program</a>) of the real-world relationship between an object and its subordinate. The <i>is-a</i> relationship may also be contrasted with the <i><a href="/facts/Typeof/mCIKwDuQ">instance-of</a></i> relationship between objects (instances) and types (classes): see <a href="/facts/Type%E2%80%93token_distinction/bowhkeL4">Type–token distinction</a>.
</p><p>To summarize the relations, there are:
</p>
<ul><li><a href="/facts/Hyperonym/bjxUuoRb">hyperonym</a>–<a href="/facts/Hyponym/bjxUuoRb">hyponym</a> (supertype/superclass–subtype/subclass) relations between types (classes) defining a taxonomic hierarchy, where
<ul><li>for a <a href="/facts/Inheritance_(object-oriented_programming)/a7R1xv8n">subsumption</a> relation: a hyponym (subtype, subclass) has a <i>type-of</i> (<i>is-a</i>) relationship with its hyperonym (supertype, superclass);</li></ul></li>
<li><a href="/facts/Holonym/Vgl30GYl">holonym</a>–<a href="/facts/Meronym/Vgl30GYl">meronym</a> (whole/entity/container–part/constituent/member) relations between types (classes) defining a possessive hierarchy, where
<ul><li>for an <a href="/facts/Aggregation_(object-oriented_programming)/zWbRC9Jd">aggregation</a> (i.e. without ownership) relation:
<ul><li>a holonym (whole) has a <i>has-a</i> relationship with its meronym (part),</li></ul></li>
<li>for a <a href="/facts/Composition_(object-oriented_programming)/zWbRC9Jd">composition</a> (i.e. with ownership) relation:
<ul><li>a meronym (constituent) has a <i><a href="/facts/Part-of/Vgl30GYl">part-of</a></i> relationship with its holonym (entity),</li></ul></li>
<li>for a <a href="/facts/Object_composition/zWbRC9Jd">containment</a><a class="footnote-ref" id="fnref:3" href="#fn:3"><sup>3</sup></a> relation:
<ul><li>a meronym (member) has a <i>member-of</i> relationship with its holonym (<a href="/facts/Container_(abstract_data_type)/gsC5UcqD">container</a>);</li></ul></li></ul></li>
<li>concept–object (type–token) relations between types (classes) and objects (instances), where
<ul><li>a token (object) has an <i><a href="/facts/Instance_(computer_science)/5zPBGdX1">instance-of</a></i> relationship with its type (class).</li></ul></li></ul>
<h2 id="examples-of-subtyping">Examples of subtyping</h2>
<p><a href="/facts/Subtyping/0L9t8twv">Subtyping</a> 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.
</p>
<h3>C++</h3>
<p>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).
</p>
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.
}
<p><a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a>
</p><h3>Python</h3>
<p>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.
</p>
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.

<p>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.<a class="footnote-ref" id="fnref:5" href="#fn:5"><sup>5</sup></a>
</p>
>>> a = 0
>>> type(a)
<type 'int'>
>>> type(type(a))
<type 'type'>
>>> type(type(type(a)))
<type 'type'>
>>> type(type(type(type(a))))
<type 'type'>

<h3>Java</h3>
<p>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 <a href="/facts/Interface_(Java)/6TmqUypv">implements</a> clauses.
</p><p>Using the Collections classes, ArrayList<E> implements List<E>, and List<E> extends Collection<E>. So ArrayList<String> is a subtype of List<String>, which is a subtype of Collection<String>. The subtyping relationship is preserved between the types automatically. When defining an interface, PayloadList, that associates an optional value of <a href="/facts/Generic_type/kqtqJk7p">generic type</a> P with each element, its declaration might look like:
</p>
interface PayloadList<E, P> extends List<E> {
    void setPayload(int index, P val);
    ...
}

<p>The following parameterizations of PayloadList are subtypes of List<String>:
</p>
PayloadList<String, String>
PayloadList<String, Integer>
PayloadList<String, Exception>

<h2 id="liskov-substitution-principle">Liskov substitution principle</h2>
<p class="note">Main article: <a href="/facts/Liskov_substitution_principle/r2vHVwa5">Liskov substitution principle</a></p>
<p>Liskov substitution principle explains a property, <i>"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,"</i>.<a class="footnote-ref" id="fnref:6" href="#fn:6"><sup>6</sup></a> Following example shows a violation of LSP.
</p><p>Here is perhaps an example of violation of LSP:
</p>
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; }
    double GetArea() const     { return GetHeight() * GetWidth(); }
  private:
    double itsWidth;
    double itsHeight;
};

<p>From a programing point of view, the Square class may be implemented by inheriting from the Rectangle class.
</p>
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);
}

<p>However, this violates LSP even though the is-a relationship holds between Rectangle and Square
</p><p>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.
</p>
void g(Rectangle& r)
{
  r.SetWidth(5);
  r.SetHeight(4);
  assert(r.GetArea()) == 20); // assertion will fail
}

<p>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.
</p><p><a class="footnote-ref" id="fnref:7" href="#fn:7"><sup>7</sup></a>
</p>
<h2 id="see-also">See also</h2>
<ul><li><a href="/facts/Inheritance_(object-oriented_programming)/a7R1xv8n">Inheritance (object-oriented programming)</a></li>
<li><a href="/facts/Liskov_substitution_principle/r2vHVwa5">Liskov substitution principle</a> (in <a href="/facts/Object-oriented_programming/TxNMEcao">object-oriented programming</a>)</li>
<li><a href="/facts/Subsumptive_containment_hierarchy/mYJyqFrG">Subsumption</a></li>
<li>Is-a
<ul><li><a href="/facts/Hypernymy/bjxUuoRb">Hypernymy</a> (and <a href="/facts/Supertype/0L9t8twv">supertype</a>)</li>
<li><a href="/facts/Hyponymy/bjxUuoRb">Hyponymy</a> (and <a href="/facts/Subtyping/0L9t8twv">subtype</a>)</li></ul></li>
<li><a href="/facts/Has-a/lyFhMcdw">Has-a</a>
<ul><li><a href="/facts/Holonymy/Vgl30GYl">Holonymy</a></li>
<li><a href="/facts/Meronymy/Vgl30GYl">Meronymy</a></li></ul></li></ul>
<h2 id="notes">Notes</h2>

<h2 id="citations">Citations</h2>

<ul><li><a href="/facts/Ronald_J._Brachman/WxVQ2rVz">Ronald J. Brachman</a>; "<a href="http://dblp.uni-trier.de/rec/bibtex/journals/computer/Brachman83">What IS-A is and isn't. An Analysis of Taxonomic Links in Semantic Networks</a>". IEEE Computer, 16 (10); October 1983</li>
<li>Jean-Luc Hainaut, Jean-Marc Hick, Vincent Englebert, Jean Henrard, Didier Roland: <a href="https://web.archive.org/web/20070211062250/http://www.informatik.uni-trier.de/~ley/db/conf/er/HainautHEHR96.html">Understanding Implementations of IS-A Relations</a>. ER 1996: 42-57</li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1"><p>See Liskov substitution principle. <a href="/wiki/Liskov_substitution_principle" target="_blank">/wiki/Liskov_substitution_principle</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li>
<li id="fn:2"><p>"Subtypes and Subclasses" (PDF). MIT OCW. Retrieved 2 October 2012. <a href="http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-170-laboratory-in-software-engineering-fall-2005/lecture-notes/lec14.pdf" target="_blank">http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-170-laboratory-in-software-engineering-fall-2005/lecture-notes/lec14.pdf</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li>
<li id="fn:3"><p>See also Containment (computer programming). <a href="/wiki/Containment_(computer_programming)" target="_blank">/wiki/Containment_(computer_programming)</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li>
<li id="fn:4"><p>Mitchell, John (2002). "10 "Concepts in object-oriented languages"". Concepts in programming language. Cambridge, UK: Cambridge University Press. p. 287. ISBN 0-521-78098-5. <a href="0-521-78098-5" target="_blank">0-521-78098-5</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li>
<li id="fn:5"><p>Guido van Rossum. "Subtyping Built-in Types". Retrieved 2 October 2012. <a href="https://www.python.org/dev/peps/pep-0253/" target="_blank">https://www.python.org/dev/peps/pep-0253/</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></p></li>
<li id="fn:6"><p>Liskov, Barbara (May 1988). Data Abstraction and Hierarchy (PDF). SIGPLAN Notices. Archived from the original on Jun 21, 2020. <a href="https://web.archive.org/web/20200621040810/https://klevas.mif.vu.lt/~plukas/resources/OODPrinciples/Liskov1987.pdf" target="_blank">https://web.archive.org/web/20200621040810/https://klevas.mif.vu.lt/~plukas/resources/OODPrinciples/Liskov1987.pdf</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></p></li>
<li id="fn:7"><p>"The Liskov Substitution Principle" (PDF). Robert C. Martin, 1996. Archived from the original (PDF) on 5 September 2015. Retrieved 2 October 2012. <a href="https://web.archive.org/web/20150905081111/http://www.objectmentor.com/resources/articles/lsp.pdf" target="_blank">https://web.archive.org/web/20150905081111/http://www.objectmentor.com/resources/articles/lsp.pdf</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></p></li>
</ol>

is-a open-in-new

is-a