Dark Hole: вопрос не звучит как "ребята, вот хочу сделать так-то и так-то, ответьте, пожалуйста, зачем мне это?", а как "Так-то и так-то, подскажите, пожалуйста, почему я сталкиваюсь со сложностями? Где неправ я, а где ООП (как возможность моделировать сущности с атрибутами и поведением)?".
Моя задача - не писать физический/игровой движок, а спроектировать модель сложного игрового мира. Это, теоретически, может лежать в основе серверной части, либо же клиентской (для синглплеерной игры). Подробности не столь важны, ибо задача учебная, исследовательская.
Сам работаю с Unity, и знаю, как себя показывает КОП, и местами, в принципе очень даже неплохо.
Мне кажется, или я не совсем корректно сформулировал вопрос?
Вот, например, шаблон Стратегия можно распознать, когда требуется выделение семейства алгоритмов, принадлежащих к одному классу (если можно так выразиться).
А у меня конкретный пример со сложной поведенческой структурой вообще всякого объекта, и, стало быть, стоит вопрос: как грамотно и можно ли вообще решить возникшую проблему с помощью ООП?
Я привёл конкретные примеры того, какая ситуация, на мой взгляд, перестала быть разрешимой в рамках современого ООП, реализованного в Java или C#, а именно - сложные сквозные поведенческие характеристики, мультклассификации и прочее, прочее.
Зачем мне это нужно? Да банально лучше отражает действительность, а значит, вероятнее всего, имеет больший потенциал по гибкости и расширяемости, по возможностям, в конце концов.
Dark Hole: да нет же, я вот как раз пытаюсь с помощью ООП написать модель своего приложения так, чтобы она отражала действительность (не настоящую, а игровую, к которой есть ряд сложных и описанных в вопросе требований).
На мой взгляд это самый эффективный вариант в этой ситуации, но я не уверен, что обладаю всеми силами и возможностями определить это с необходимой точностью, так что спасибо за комментарий и мнение!
Также рассматривал данный вариант, который может помочь в случае с небольшой системой, однако имеет, на мой взгляд (я могу ошибаться), ряд недостатков:
1. Гитара ответственна за то, как её можно использовать. Если допустить существование ещё N гитаро-подобных объектов (камни, вёдра, ящики, заборы), то окажется, что для каждого поведенческого свойства, не присущего гитаре как таковой, придётся реализовывать дополнительные интерфейсы, всегда и везде в каждом объекте. Более того, для каждого частного случая, скажем, камня, придётся создавать отдельный тип только ради того, чтобы реализовать некоторые поведенческие свойства. Ну, например, камень - был просто `Thing` с именем "Небольшой камушек", а захотели сделать его подбираемым - придётся создавать тип `Rock` и реализовывать интерфейс отдельно для него.
Есть ещё вариант: в `Thing` реализовать `IPickupable`. Тогда возникает дилемма - не все вещи подбираемые.
Другой вариант: инкапсулировать `IPickupable` в `IPickupBehaviour` и применить инъекцию зависимости прямо в класс `Thing`, дабы затем иметь возможность, по меньшей мере, динамически изменять поведение. Это приведёт к тому, что `Thing` раздуется до такой степени, что, во-первых, не будет никакого смысла делать от него наследников, потому как все поведенческие свойства уже и так в нём есть, а, во-вторых, сломает SRP самой абстракции `Thing` (я не говорю о реализации, они ведь скрыты в стратегиях).
Все вышеперечисленные варианты я рассматривал, но не пришёл ни к чему подходящему. Это связано с тем, что, в действительности, объекты (что бы мы ими не называли) ведут себя, как будто бы, немного не так. Например, в голове у меня существует агрегат "Бутылка" с атрибутами "Открыть", "Количество жидкости внутри", но, в действительности, все эти атрибуты определяются не агрегатом, а его структурой, то бишь наличием крышки, прозрачной жидкости внутри, пластиковой тарой, к которой прикреплена жидкость. Пластик напоминает мне о том, что её можно поджечь. Сам агрегат "Бутылка с водой" намекает на то, что я могу утолить жажду, освежиться, запить таблетки, и многое-многое другое.
Совершенно не уверен, что это ООП в том свете, в котором его ранее понимал и использовал...
AtomKrieg: если про тот, что в заголовке, то вы абсолютно правы. Прошу прощения, если нарушил правила, но старался максимально точно описать, с чем именно возникают трудности, и как я пытался их решить собственными силами.
Спасибо за комментарий
Вы абсолютно правы, и сейчас я бы хотел решить пункт номер один, потому что те инструменты, которые есть в моём распоряжении, не выглядят способными помочь, отчего обращаюсь к опытным коллегам, т.к. сам являюсь тем ещё новичком!