При попытке объяснить концепцию наследования в ООП, типичным примером часто является пример млекопитающих. ИМХО, это действительно плохой пример, потому что это заставит новичков неправильно использовать эту концепцию. Более того, это не обычный дизайн, с которым они столкнутся в своей повседневной работе.

Итак, что будет хорошей, простой и конкретной проблемой, которая решается с помощью Inheritance?

Нет ничего плохого в чисто академическом примере, подобном млекопитающим. Мне также нравится пример прямоугольника / квадрата, потому что он указывает, почему реальные таксономии не всегда напрямую переводятся в ожидаемые отношения наследования.

На мой взгляд, наиболее каноническим примером на каждый день является GUI инструментарий. Это то, что все использовали, но новички, возможно, не рассуждали о том, как они работают под капотом. Вы можете говорить о том, какое поведение является общим для всех контейнеров, всех виджетов, событий и т. Д., Не требуя детального знания какой-либо конкретной реализации.

Мой реальный пример - доменная модель простого HR-приложения. Я говорю, что мы можем создать базовый класс с именем Employee , потому что, конечно, менеджеры тоже являются сотрудниками.

public class Employee
{
    public string FirstName { get; set; }

    public string LastName { get; set; }

    public int Code { get; set; }

    public string GetInsuranceHistory()
    {
        // Retrieving insurance history based on employee code.
    }
}

Затем я объясняю, что разработчики - это сотрудники , тестеры - это сотрудники , руководители проектов - сотрудники . Таким образом, они все могут наследовать от класса работников.

Инкапсулируйте то, что меняется ... покажите им шаблон шаблонного метода , он демонстрирует полезность наследования, помещая общее поведение в базовый класс и инкапсулируя различное поведение в подклассы.

UI controlsи Streamsтакже являются очень хорошим примером полезности наследования.

Помнить

Каждый экземпляр объекта является конкретным примером полезности наследования!

Если вы имеете в виду именно наследование классов , то теперь вы находитесь в мире таксономий, и они будут сильно различаться в зависимости от целей системы, которая их использует. В примере с животными / млекопитающими используется общая и, как мы надеемся, знакомая таксономия из биологии, но она (как вы упомянули) почти бесполезна для подавляющего большинства задач программирования.

Так что попробуйте что-нибудь универсальное: понятие программы. Каждая программа запускается, запускается и заканчивается. У каждой программы есть имя и необязательные параметры командной строки. Таким образом, базовый класс Program был бы очень полезен для запуска выполнения, сбора и обработки аргументов командной строки, запуска основной логики и корректного завершения работы.

Вот почему так много объектно-ориентированных языков программирования предоставляют класс Program или что-то, что ведет себя точно так же, как класс Program.

Я работаю с камерами на работе. У нас есть устройства, которые подключаются к разным моделям, поэтому у нас есть абстрактный «класс камеры», и каждая модель наследуется от этого класса для поддержки определенных функций этой камеры. Это пример из реального мира, и его нетрудно понять.

Пример Химических Элементов

Это еще один пример из моего мозга:

класс Element_
{
    двойной атомный вес; // Атомный вес элемента
    двойной атомный номер; // Атомный номер элемента
    Свойства строки; // Свойства элемента
    // Другие, если есть
}


Изотоп класса расширяет Element_ // Изотопы элемента могут существовать
{
    двойной период полураспада;
   // Другие, если есть

}

Реальные примеры почти всегда ошибаются, потому что они приводят примеры, где всегда есть вероятность того, что что-то есть TypeAи то, и другое, TypeBно иерархия единого наследования во многих языках не позволяет этого.

Чем больше я программирую, тем больше ухожу от наследства.

Даже слово «наследовать» здесь используется неправильно. Например, вы наследуете около 50% черт вашего отца и 50% черт вашей матери. На самом деле ваша ДНК - это составная часть половины ДНК вашего отца и половины ДНК вашей матери. Это потому, что биология на самом деле предпочитает композицию наследованию , и вы тоже должны.

Простая реализация интерфейсов, или, что еще лучше, «типизирование утки», плюс внедрение зависимостей, - гораздо лучшая вещь для обучения людей, плохо знакомых с объектно-ориентированным программированием.

Я бы просто показал им пример из жизни. Например, в большинстве сред пользовательского интерфейса вы создаете свой собственный класс "Dialog", "Window" или "Control".

Хорошим примером является функция сравнения в сортировке:

template<class T>
class CompareInterface {
public:
   virtual bool Compare(T t1, T t2) const=0;
};
class FloatCompare : public CompareInterface<float> { };
class CompareImplementation : public FloatCompare {
public:
   bool Compare(float t1, float t2) const { return t1<t2; }
};
template<class T>
void Sort(T*array, int size, CompareInterface<T> &compare);

Единственная проблема в том, что новички слишком часто думают, что производительность важнее хорошего кода ...

Мой пример из реального мира - это транспортное средство:

public class Vehicle
{
    public Vehicle(int doors, int wheels)
    {
        // I describe things that should be
        // established and "unchangeable" 
        // when the class is first "made"
        NumberOfDoors = doors;
        NumberOfWheels = wheels;
    }

    public void RollWindowsUp()
    {
        WindowsUp = true;
    }

    // I cover modifiers on properties to show
    // how to protect certain things from being
    // overridden
    public int NumberOfDoors { get; private set; }
    public int NumberOfWheels { get; private set; }

    public string Color { get; set; }
    public bool WindowsUp { get; set; }
    public int Speed { get; set; }
}

public class Car : Vehicle
{
    public Car : base(4, 4)
    {

    }
}

public class SemiTruck : Vehicle
{
    public SemiTruck : base(2, 18)
    {

    }
}

Этот пример может быть настолько подробным, насколько вам угодно, и к транспортным средствам прикреплены всевозможные свойства, объясняющие использование любых модификаторов, которым вы, возможно, захотите научить.

Этот пример не-млекопитающих, не-птиц, не-рыб может помочь:

public abstract class Person {

    /* this contains thing all persons have, like name, gender, home addr, etc. */

    public Object getHomeAddr() { ... }

    public Person getName() { ... }

}

public class Employee extends Person{

    /* It adds things like date of contract, salary, position, etc */

    public Object getAccount() { ... }

}

public abstract class Patient extends Person {
    /* It adds things like medical history, etc */
}

потом

public static void main(String[] args) {

    /* you can send Xmas cards to patients and employees home addresses */

    List<Person> employeesAndPatients = Factory.getListOfEmployeesAndPatients();

    for (Person p: employeesAndPatients){
        sendXmasCard(p.getName(),p.getHomeAddr());
    }

    /* or you can proccess payment to employees */

    List<Employee> employees = Factory.getListOfEmployees();

    for (Employee e: employees){
        proccessPayment(e.getName(),e.getAccount());
    }       

}

ПРИМЕЧАНИЕ: только не говорите секрет: человек расширяет Млекопитающее.

Как насчет иерархии алгебраических выражений. Это хорошо, потому что включает в себя как наследование, так и состав:

+--------------------+------------------------+
| Expression         |<------------------+    |
+--------------------+----------+        |    |
| + evaluate(): int  |<---+     |        |    |
+--------------------+    |     |        |    |
          ^               |     |        |    |
          |               |     |        |    |
   +--------------+  +---------------+  +-------------+  ...
   | Constant     |  | Negation      |  | Addition    |
   +--------------+  +---------------+  +-------------+
   | -value: int  |  |               |  |             |
   +--------------+  +---------------+  +-------------+
   | +evaluate()  |  | +evaluate()   |  | +evaluate() |
   | +toString()  |  | +toString()   |  | +toString() |
   +--------------+  +---------------+  +-------------+

   Addition(Constant(5), Negation(Addition(Constant(3),Constant(2))))
   (5 + -(3 + 2)) = 0

За исключением корневого выражения Constant, все остальные выражения являются выражениями и содержат одно или несколько выражений.

Я буду использовать птиц в качестве примера

как курица, утка, орел

Я объясню, у обоих есть когти, клевки и крылья, но их атрибуты разные.

Цыплята не могут летать, не умеют плавать, могут есть червей, могут есть зерно

Утки не могут летать, могут плавать, могут есть зерно, не могут есть червей

Орел может летать, не умеет плавать, может есть червей, не может есть зерно

Ваш типичный rails-clone предоставляет много практических примеров : у вас есть (абстрактный) класс базовой модели, который инкапсулирует все манипуляции с данными, и у вас есть базовый класс контроллера, который инкапсулирует все HTTP-коммуникации.