Is-a

Отношение «is-a» («является частным случаем»), в отличие от отношения «has-a» («имеет») между типами (классами), необходимо различать при проектировании моделей (например, компьютерной программы), чтобы не допустить ошибочного смешения иерархии наследования и иерархии композиции. Кроме того, отношение «is-a» отличается от отношения «является экземпляром» между объектами (экземплярами) и их типами или классами (см. различие типа и сущности). В современном объектно-ориентированном программировании предпочтение часто отдаётся композиции (отношение «has-a») перед наследованием («is-a»). Композиция обеспечивает слабую связанность, большую гибкость и значительно упрощает модульное тестирование, в частности, мокирование зависимостей^[2].^[3]

Краткое описание различных отношений:

• гипероним-гипоним (надтип/надкласс — подтип/подкласс): отношения между типами (или классами), определяющие таксономическую иерархию. Для отношения субсумпции: гипоним (подтип, подкласс) находится в отношениях «is-a» со своим гиперонимом (надтипом, надклассом);
• холонимия-меронимия («целое»/«контейнер» — «часть»/«элемент»): отношения между типами (или классами), определяющие иерархию владения и включения.

Для отношения агрегации (без владения): холоним (целое) находится в отношении «has-a» («имеет») со своим меронимом (частью). Для отношения композиции (с владением): мероним (конституент) находится в отношении «является частью» по отношению к своему холониму (целому). Для отношения containment (контейнирования): мероним (элемент) — в отношении «является членом» со своим холонимом (контейнером)^[4].

• концепт-объект (тип-экземпляр): отношение между типом (или классом) и его объектами (экземплярами), где экземпляр находится в отношении «является экземпляром» («instance of») по отношению к своему типу (классу).

В современных языках онтологий, таких как OWL 2, строгое различие между отношениями «is-a» (подкласс) и «instance-of» (экземпляр) может размываться благодаря механизму punning (каламбур). Этот механизм позволяет использовать один и тот же идентификатор одновременно в качестве класса и экземпляра для целей метамоделирования^[5].

Подтипизация позволяет заменить один тип другим типом или абстракцией. Таким образом, подтипизация устанавливает отношение is-a между подтипом и определённой абстракцией — в зависимости от возможностей языка либо явно (эксплицитно), либо неявно. В языках программирования с поддержкой наследования как механизма подтипизации это отношение выражается непосредственно через наследование.

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 может быть подставлен вместо A
}

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 может быть подставлен вместо A

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

interface PayloadList<E, P> extends List<E> {
    void setPayload(int index, P val);
    ...
}

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

Принцип подстановки Лисков (LSP) формулирует корректность подтипизации следующим образом: «Если для любого объекта o1 типа S существует объект o2 типа T, такой, что во всех программах P, написанных в терминах T, поведение P остаётся неизменным при замене o2 на o1, то S является подтипом T»^[11].

Следующий пример иллюстрирует нарушение принципа подстановки Лисков:

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;
};

С точки зрения кода, класс Square может быть реализован с наследованием от Rectangle:

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);
}

Однако такая реализация нарушает LSP: несмотря на отношение «is-a» между обобщённым прямоугольником и квадратом, подстановка подкласса «Квадрат» вместо «Прямоугольник» может привести к некорректному поведению.

Рассмотрим, например, следующую функцию, где предположенный результат не выполняется, если передаётся экземпляр класса Square:

void g(Rectangle& r)
{
  r.SetWidth(5);
  r.SetHeight(4);
  assert(r.GetArea() == 20); // утверждение не выполнится!
}

Если же рассматривать ограничение на тип фигуры как на отношение между размерами, то предположения в g() (например, что SetHeight изменяет только высоту, не затрагивая ширину) могут быть неверными не только для настоящих квадратов, но и для других подклассов Rectangle, поведение которых может быть специальным^[12].

Концептуальное (таксономическое) отношение «is-a» не всегда гарантирует поведенческую подтипизацию. Принцип подстановки Лисков требует строгого соблюдения контрактов и ожидаемого поведения базового типа^[13].

Принцип подстановки Лисков фундаментально применим к семантическим моделям данных и онтологиям (например, OWL). Отношение rdfs:subClassOf требует полного соответствия подкласса семантике надкласса для обеспечения корректности логических выводов.