Admin IsAn Сотрудники не подходят для наследования?

У меня есть этот сценарий, который будет смоделирован диаграммой классов UML, и я не согласен с комментарием, выделенным полужирным шрифтом.Admin IsAn Сотрудники не подходят для наследования?

Курсы могут принадлежать категории и каждая категория присваивается свой собственный администратору, который также является работник (может быть изменен, для этого не целесообразно решить путем наследования) ,

Почему работник < | == Администратор не подходит для наследования? Я думаю, что это явно «есть», а не «есть». То, что они могут «переключить», может быть легко разрешено путем литья с обеих сторон. Дополнительные атрибуты будут удалены, недостающие будут инициализированы значением NULL или некоторым значением по умолчанию.

источник

2017-01-13 Slazer

Что означает «изменить»? Что изменится? Я считаю, что это заявление неоднозначно. –

@ThomasKilian Это означает, что Администратор может стать Рабочим (быть пониженным в должности) и наоборот (быть продвинутым). – Slazer

Хотя это четко не указано, но часть

не целесообразно решить путем наследования

дает вам подсказку, как понять

может быть изменен

Важная часть, которая может быть наследства, если не было скобка части приходит из этой части

администратора, который также является сотрудник

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

источник

2017-01-13 12:08:15 Ister

Еще много читать листья чая. Я бы попросил автора цитаты из ФП, что он на самом деле имел в виду. Нельзя создавать на основе спекуляций. –

@Ister Thats умное объяснение, хотя оно просто означает «быть пониженным до должности от сотрудника Admin до сотрудника Employee». Я вижу проблему, которую вы продемонстрировали, но рассмотрите теперь предполагаемое значение. Автор цитаты утверждает, что проблема заключается в том, что объект должен быть отброшен. Я не согласен, почему это проблема? Автор присваивает ассоциацию вместо наследования, но опять же ее отношение «IsA». Это может сработать, но семантически это просто не так. – Slazer

Рассмотрим эту модель (я сливались две модели в одном здесь):

В чем разница между левым и правым редакторам? Левый имеет все атрибуты и операции с унаследованным Employee, что делает их доступными для Category. Но это должно быть возможно только для взаимодействия с частью Admin. В правильной версии Admin может сделать это Employee -отложение закрытое и, следовательно, оно недоступно для Category.

В любом случае необходимо обработать pro/demote, удалив его с Category. Так как насчет времени выполнения? Когда вы имеете дело с Admin, который унаследовал, вы просто использовали бы этот объект во всех операциях, где требуется Employee. Теперь, когда он больше не админ, что делать? Вы должны создать простой Employee и дать ему те части, которые необходимы от прежних Admin.