Почему наследование плохо в модели Person-Student?

Почему наследование плохо в модели Person-Student?
Почему наследование плохо в модели Person-Student? - preindl @ Unsplash

Я только что начал изучать тему "Наследование и композиция", и по какой-то причине мне сложно разобраться в этом.

У меня есть такие классы:

Person

class Person
{
    public string Name { get; set; }
    public int Age { get; set; }

    public Person(string name)
    {
        Name = name;
    }

    public override string ToString()
    {
        return Name;
    }

    public virtual void Greet()
    {
        Console.WriteLine("Hello!");
    }
}

Учитель

class Teacher : Person
{
    public Teacher() : base("empty")
    {
    }

    public override void Greet()
    {
        base.Greet();
        Console.WriteLine("I'm a teacher");
    }
}

Студент

class Student : Person
{
    public Student() : base("empty")
    {
    }

    public override void Greet()
    {
        base.Greet();
        Console.WriteLine("I'm a student!");
    }
}

И мне сказали следующее:

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

И я не очень понимаю, почему.

Прежде всего, что означает домен модели? Также, если я не должен использовать наследование, должен ли я использовать композицию? Если да, то как будет выглядеть мой код? И еще, что это за "очень болезненные проблемы", которые могут возникнуть?

Проблема с этой моделью заключается в том, что учитель и ученик — это роли, а человек — реальная сущность. Хотя эта модель будет работать в краткосрочной перспективе, у нее будут проблемы, если: студент станет учителем, или если учитель пройдет курс, став студентом (или также если студент закончит обучение и больше не будет студентом).

Ученик и Учитель — это эфемерные роли (играемые людьми), тогда как Человек — это постоянная сущность.

Таким образом, отношения между Учеником и Человеком или между Учителем и Человеком неуместны.


Кроме того, если я не должен использовать наследование, должен ли я использовать композицию?

Да, использование композиции позволит ролям Person появляться и исчезать без необходимости создавать/уничтожать новый объект Person. Вам просто нужно смоделировать, что объект Person может иметь отношения с объектами ролей.

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


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


Прежде всего, что означает домен модели?

Цель модели предметной области состоит в том, чтобы иметь возможность собирать информацию, чтобы иметь возможность позже ответить на вопросы, которые вы хотите задать.

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

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

Затем мы пытаемся моделировать ровно столько, сколько нужно для этого: не переусердствуйте с моделированием вещей, с которыми автоматизация не поможет (например, нам не нужно множество классов, когда достаточно объектов и полей), и все же моделируйте в достаточной степени. что автоматика работает нормально.

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


LetsCodeIt, 19 декабря 2022 г., 01:26