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