Распространенным решением построения модели системы, состоящей из множества элементов разных типов, является создание модульной системы, в которой каждый модуль отвечает за определенный тип. Например, будет модуль для вомбатов WombatModule:IModule, где интерфейс IModule имеет такие методы, как GetCount() (для определения количества вомбатов) и Update() (для обновления состояния всех вомбатов).
Более объектно-ориентированный подход состоял бы в том, чтобы иметь класс для каждого типа элемента и создавать экземпляр для каждого элемента. Это создаст класс Wombat:IItem с такими методами, как Update() (для обновления этого вомбата).
С точки зрения кода разница незначительна, но время выполнения существенно отличается. Модульно-ориентированное решение, безусловно, быстрее: меньше создания объектов, легче оптимизировать операции, общие для всех вомбатов.
Проблемы возникают, когда количество типов и модулей растет. Либо вы теряете большую часть преимущества в производительности, потому что каждый модуль поддерживает только несколько элементов, либо сложность модулей возрастает, чтобы приспособиться к немного отличающимся элементам одного общего типа — скажем, толстым и худым вомбатам. Или оба.
По крайней мере, один раз я видел, как он деградировал до плохого состояния, когда все, что делает WombatModule, — это хранит коллекцию скрытых объектов Wombat и запускает их методы в цикле.
Когда производительность является меньшей проблемой, чем долгосрочная разработка, можете ли вы определить какие-либо архитектурные причины для использования модулей вместо отдельных объектов? Может быть, есть еще одна возможность, которую я упускаю?
