Архитектурные стратегии для избежания динамических забросов - PullRequest
5 голосов
/ 09 июня 2011

Часто читают, как стоит разрабатывать ваш код, чтобы избежать необходимости делать приведения, и как найти себя нужным для приведения может предположить, что существует лучшая доступная реализация.Я пытаюсь достичь этого священного грааля «кода без приведения» в реализации механизма виртуального мира, где многие объекты имеют широкий спектр интерфейсов, выступая в качестве посредников и данных (а иногда и обоих) множества различных форм.,Как упоминается в одном ответе на аналогичный вопрос ( Linkage ), цель состоит в том, чтобы всегда иметь ссылку / указатель правильного типа в требуемом месте, а не пытаться выкопать один из большого числа объектов-кандидатов..

Моя последняя попытка решить эту большую проблему - это регистрация объектов с их посредниками, что имеет некоторые приятные преимущества с точки зрения гранулярности управления (вы можете во время выполнения настроить множество сопоставлений между посредниками и их целями).

Есть и некоторые проблемы ... Самая большая проблема, которую я сейчас наблюдаю, - это отмена регистрации целей от посредников.Чтобы отслеживать, кто чем пользуется, не опрашивая каждого возможного посредника, программе необходимо хранить еще больше данных о том, какие ссылки были созданы.С одной стороны, для посредников было бы возможно отключить себя, просто проверив, истек ли срок их цели (я использую умные и слабые указатели для всего, так что это не сложно), однако это просто обрабатывает истечение объектов и делаетне создавать основы для существенной реконфигурации поведения.

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

Я хочу спросить, что вы думаете о структурировании программ, чтобы избежать динамического приведения, и не могли бы вы поделиться какими-либо стратегиями / шаблонами, которые эффективны в этих ситуациях.

1 Ответ

3 голосов
/ 09 июня 2011

Это принципиально ошибочное предложение. dynamic_cast существует по причине. Попытка нацелиться на код без использования кода - это просто наивные цели. Конечно, это может быть лучшим способом уменьшить их, где вы можете, но это сильно отличается от попыток запретить их. Код без dynamic_cast не является своего рода святым Граалем - либо он не нужен, в этом случае это просто код, либо он действительно нужен, и в этом случае это неоптимальный код.

Тем не менее, чтобы остаться немного в стороне от темы, я лично обнаружил, что, просто не распространяя наследование вокруг, как будто это Чума, и я пытаюсь вызвать Апокалипсис, тогда необходимость в кастинге ограничена - шаблоны являются чудом здесь.

...