Я обычно выбираю разновидность варианта 1.3 - класс, содержащий Set/Map/List других классов. То есть, работаю с двумя сущностями - Entity и EntityCollection.
Да, этот подход требует создания двух классов, но он оправдывает себя в долгосрочной перспективе, особенно, если я вижу, что в класс Entity в будущем можно будет добавить методы, работающие с данными класса.
Как минимум в классе Entity я добавлю аналог метода toString(), для удобного отображения его содержимого в infolog-е, и методы set()/get(), поставив точку останова на которых другие разработчики смогут контролировать работу с этими классами.
Кроме того, в данном варианте, код работающий с этими классами выглядит гораздо понятнее и проще, за счет того, что все низкоуровневые манипуляции с данными (conpeek/conpoke/работу с индексами/проверки) я прячу в методы этих классов, имеющие говорящие имена и сразу понятные разработчику.
В будущем иногда бывает полезно создать класс EntityIterator для того, чтобы перебирать элементы коллекции. Кроме того, интерфейс для работы с моей коллекцией в этом случае будет выглядеть схожим образом с интерфейсом стандартных коллекций и их итераторов.
|