Почему наследование является плохой практикой в ​​дизайне контрактов сообщений

Question

По мнению создателей MassTransit, наследование на основе классов не считается хорошей практикой - https://masstransittemp.readthedocs.io/en/latest/overview/inheritance.html

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

public class InsurancePolicyEvent
    {
        Guid EventId { get; set;} 

        Guid PolicyId { get; set; }

        InsuranceProduct Product { get; set;}
    }

Почему я не могу просто использовать наследование здесь и не повторять себя в унаследованных событиях, например так:

 public class PolicyTerminated : InsurancePolicyEvent
 {
    ...
 }

 public class PolicyIssued : InsurancePolicyEvent
 {
    ...
 }

Answer 1

Чтобы прояснить мою позицию, MassTransit рекомендует использовать интерфейсы вместо классов и совершенно доволен базовым типом, подобным тому, который вы показали выше, особенно когда это обязательное применение полей в качестве типа события.

Наследование на основе интерфейса в порядке, не бойтесь, но не сходите с ума.

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

Однако, как только ваш InsuranceProduct класс начинает эволюционировать, и некоторые ожидания поведения диспетчеризации виртуальных методов базового класса начинают ползти в модель, что ведет к плохим временам. И это может быть не вы, это может быть менее опытный разработчик, который научился проектировать классы ОО и понял, почему не так?

Так что будьте осторожны там:)