علاقة Is-a  في تمثيل المعرفة، البرمجة والتصميم الكينوني (انظر بنية البرنامج الكينوني)، ((is_a or is a)) هي علاقة من العلاقات الفرعية خاصية التجريد كما في (الكلاسات، الفئات)، حيث يكون كلاس A هو فئة فرعية من كلاس B أخرى (وبالتالي فإن B هي فئة فائقة من A). بمعنى آخر، النوع A هو نوع فرعي من النوع B عندما تتضمن مواصفات A مواصفات B. أي أن أي كائن (أو فئة) يفي بمواصفات A يفي أيضًا بمواصفات B  في نفس الوقت، لأن مواصفات B أضعف.  يجب أن تكون العلاقة is-a متناقضة في مع علاقة ("has_a" or "has a") بين أنواع (الكلاسات)؛ إن الخلط بين العلاقات "هو has-a" و "is-a" هو خطأ شائع عند تصميم نموذج (على سبيل المثال، برنامج كمبيوتر) للعلاقة الواقعية بين كائن ما ومرؤوسه. ويمكن لهذه العلاقة ان تتعارض مع مثيلاتها من العلاقات الباقية والتي يمكن أن تكون بين الكائنات (حالات) وأنواع (الكلاسات): انظر «من نوع رمزي التمييز» و «علاقات من نوع رمزي».  لتلخيص العلاقات لدينا:   يتيح التصنيف الفرعي استبدال نوع معين بنوع أو تجريد النوع الآخر. التصنيف الفرعي يكون لإنشاء علاقة is-a بين نوع فرعي وبعض التجريد القائم، إما علنيا أو ضمنيا، اعتمادا على دعم اللغة. يمكن التعبير عن العلاقة بشكل صريح عبر الوراثة باللغات التي تدعم الوراثة كآلية تصنيف فرعي.  ينشئ كود C ++ التالي علاقة وراثية صريحة بين الفئتين B و A ، حيث B هي فئة فرعية ونوع فرعي اخر من A ، ويمكن استخدامها ك A حيثما يتم تحديد B (عبر مرجع أو مؤشر أو الكائن نفسه)). class A  class B : public A  void UseAnA(A const& some_A)  void SomeFunc()  ينشئ رمز بايثون التالي علاقة وراثية صريحة بين الفئتين B و A ، حيث يكون B فئة فرعية ونوعًا فرعيًا من A ، ويمكن استخدامه ك A حيثما كان مطلوبًا B.  class A:  class B(A):  def use_an_a(some_a):  def some_func():  المثال التالي، النوع (أ) هو نوع «عادي»، والنوع (النوع (أ)) هو نوع من بيانات. على الرغم من توزيع جميع الأنواع على نفس نوع البيانات الوصفية (PyType_Type ، وهو أيضًا نوعها الخاص)، إلا أن هذا ليس شيء متطلب. نوع الفصول الكلاسيكية، والمعروف باسم الأنواع. ClassType ، يمكن أيضًا اعتباره نوعًا متميزًا.  »> 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 ، هي علاقة بين معلمات لفئة أو واجهة واحدة، ومعلمات النوع لفئة أخرى يتم تحديدها بواسطة الجمل الموسعة وتنفذ.  باستخدام فئات المجموعات، المصفوفة <E>، ترث القائمة ووبالتالي توسع المجموعة <E>. لذا فإن المصفوفة من نوع string هو نوع فرعي من القائمة <String> ، وهو نوع فرعي من المجموعة <String>. يتم الحفاظ على علاقة الأنواع الفرعية والأنواع تلقائيًا. عندما نحدد واجهة، PayloadList ، تربط قيمة اختيارية من النوع العام P بكل عنصر، قد يبدو إعلانه كما يلي:  interface PayloadList<E, P> extends List<E> {  المعلمات التالية من PayloadList هي أنواع فرعية من القائمة <سلسلة>:  PayloadList<String, String> PayloadList<String, Integer> PayloadList<String, Exception>  يشرح مبدأ استبدال Liskov خاصية، "«إذا كان لكل كائن o1 من النوع S يوجد كائن o2 من النوع T بحيث لا يتغير سلوك P لجميع البرامج P المحددة من حيث T ، عندما يتم استبدال o1 بـ o2 ثم S هو نوع فرعي من T»". يوضح المثال التالي انتهاك LSP. void DrawShape(const Shape& s) من الواضح أن الدالة DrawShape تم تنسيقها بشكل سيئ. يجب أن تعرف كل فئة مشتقة من فئة الشكل. أيضا، يجب تغييره كلما تم إنشاء فئة فرعية جديدة من الشكل. في التصميم الموجه للكائنات  فيما يلي مثال أكثر دقة على انتهاك LSP:  class Rectangle  يعمل هذا بشكل جيد ولكن عندما يتعلق الأمر بالفئة المربعة، التي ترث فئة المستطيل، فإنها تنتهك LSP على الرغم من أن العلاقة هي علاقة بين المستطيل والمربع. لأن المربع مستطيل. يتجاوز المثال التالي وظيفتين، Setwidth و SetHeight ، لإصلاح المشكلة. لكن إصلاح الرمز يعني أن التصميم معيب.  public class Square : Rectangle void Square::SetWidth(double w) void Square::SetHeight(double h)  المثال التالي، الوظيفة g تعمل فقط لفئة المستطيل ولكن ليس لـ Square ، وبالتالي تم انتهاك مبدأ الإغلاق المفتوح.  void g(Rectangle& r)