Как стать автором
Обновить

Ответ на Решетчатое наследование

Время на прочтение 3 мин
Количество просмотров 3.3K
Эта публикация — ответ на текст «Решетчатое наследование», опубликованный хабрапользователем potan, с предложением альтернативы, на субъективный взгляд автора, более близкой к ООП с классами (для случая с ограниченным набором классов).

«Целью наследование является привязка кода (набора методов) к минимальному набору свойств сущности (как правило — объекта), которые он обеспечивает и которые ему требуются».

Разве это так? К тому же в чём причина привязки? По каким признакам мы делаем вывод, что вот эти методы с этим объектом связать, а вот какие-то другие сделать частью других объектов, которые будут брать недостающие свойства/параметры через публичные интерфейсы?

Я придерживаюсь SOLID и идеи единственной ответственности на объект. Следовательно, иерархии наследования в таком случае — это уточнения ответственности к конкретным обстоятельствам, в которых ей надо исполняться.

Однако, объекты реального мира (либо предметной области) могут нести в себе несколько разных функций/ответственностей, поэтому прямого отображения их в систему классов может не получится. Такой объект в системе классов приложения я вижу как набор/контейнер из ответственностей, поддерживаемых объектом предметной области. Задача такого класса — ответственности между собой согласовывать. Согласование частично происходит через специфических потомков ответственностей, частично внутри класса контейнере.

Постараюсь привести пример близкий к примеру статьи.

Умения
  • умение стрелять
  • умение стрелять из ПЗРК
  • умение плавать
  • умение ходить


Умение — предоставляет общую информацию, например, связь с деревом умений и слот для предметов умения.

Умение стрелять — предоставляет возможность целиться, в слоте умений должно быть стреляющее оружие.

Умение стрелять из ПЗРК — уточняет реализацию функции целиться, например, экран ПЗРК рисует.

Умение плавать — позволяет погружаться в воду (например, не умирая при этом) и показывает шкалу времени, персонаж как-бы летает в воде.

Кстати, вот тут я пропустил абстракцию — умение передвигаться, от которой унаследовать можно умения плавать и ходить.

Тогда конкретные персонажи будут содержать наборы умений.

Персонаж:
  • текущее умение передвигаться;
  • список умений: [].


Пехотинец (Персонаж):
  • текущее умение стрелять;
  • список умений: [плавать, ходить, стрелять из ПЗРК].


Утка (Персонаж):
  • список умений: [плавать].


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

Вопрос: что же будет, если данная набор будет разрастаться?
А как он может разрастаться?
  • добавить новое умение;
  • добавить нового персонажа;
  • добавить существующему персонажу умение, которое ранее ему было не свойственно (научить утку стрелять из ПЗРК).


Новое умение:
.Eсли это количественные вещи, например, ПЗРК стрелял с вероятностью попадания 0.6, а теперь 0.8 — так это просто разные записи в бд одного и того-же класса.

.Если что-то новое, например, меч — тогда в любом случае нужна гора кода, которая в начале владение мечом абстрактно опишет, а потом у каждого персонажа свои детали добавит. Хотя не обязательно сложная модификация (если абстракции Персонажа и его наследников хороши).

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

Сложнее существующему добавить ещё что-то, т.к. нужно внутренний код существующего перебирать заново. И возможно, проще будет унаследовать потомка.

Например, Утка нас всем устраивает, только вот стрелять не умеет. Значит, этот функционал надо наложить, может удобнее будет даже сразу 2 класса добавить: Простая Утка и Утка, умеющая стрелять. А в классе Утка оставить общие для дочерних уток ответственности — умение плавать — приспособленное к утке: в виде держаться на воде и нырять.

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

С такой позиции mixin кажется недовыделенными классом. Недовыделенным его оставили из-за стремления сделать быстрее и не перестраивать существующие иерархии классов и их композиции.
Теги:
Хабы:
0
Комментарии 10
Комментарии Комментарии 10

Публикации

Истории

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн