Как я могу сделать шаблон стратегии поддерживаемым, не ставя его под угрозу?

Question

Я борюсь с дизайном, который отвечает всем моим требованиям

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

1. Эти алгоритмы могут быть дорогостоящими, и если они запускаются один раз, результат должен быть обналичен для последующего использования.

2. Алгоритмы могут использоваться в различных контекстах.

3. Алгоритмы должны быть открыты для расширения, чтобы они могли не отставать от ежегодных пересмотров стандартов.

4. Проект должен быть ремонтопригодным

Моей первой попыткой удовлетворить их было использование шаблона стратегии со следующим дизайном…



Вывод из расчеты поведений кэшируются в самих поведениях.

Это удовлетворяет требованиям 1,2,3, но не 4.

Для вызова CalculateOutput () требуется 30 различных параметров, своих и их Необходимо позволить ему вызывать другие конкретные поведения. Изменение параметров для одной функции будет иметь эффект детонации и часто приводит к тому, что все поведения будут вынуждены обновлять свой список параметров.

Кроме того, система кэширования работала некорректно, поскольку не всегда Соотношение 1: 1 между поведением. Например, чтобы создать вывод из EnergyBehaviour, ему нужно выполнить несколько вызовов NHSolarPosition. Как «NHSolarPosition» может кэшировать несколько «angleOfIncidence_» только для одного кэшированного «outPut _»?

Я попытался решить вышеуказанную проблему, инкапсулировав все параметры в их собственный тип «PVPanel» и передав его поведения. Это было проблематично c по двум причинам. Во-первых, при обращении к простому поведению возникали значительные накладные расходы, поскольку могла потребоваться только пара параметров, однако было много других параметров, которые не использовались или не относились к делу. Во-вторых, передача типа «PVPanel» в поведение привела к сбою требования 2. Я не смог использовать поведение в контексте, отличном от PVPanels.

Я изо всех сил стараюсь согласовать все свои требования с единый элегантный дизайн.

Answer 1

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

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

Комментарий к вашему вопросу предлагает std::map параметров. Другой вариант - указать c класс параметров для расчетов. Посмотрите на шаблон посетителя или std::variant, как обернуть эти указанные c типы параметров.

std::map может быть проще, так как это может решить вашу проблему с PVPanel и требованием 2. Это будет просто случай заполнения std::map из экземпляра PVPanel или любого другого типа. В качестве альтернативы вы можете использовать методы доступа типа PVPanel и просто переместить их в интерфейс, который реализуют PVPanel и другие будущие типы.