Я надеюсь, что это не воспринимается оскорбительно, но я не могу не думать, что этот дизайн является чрезмерно причудливым решением для довольно простой проблемы.
Почему вам нужно, например, объединять мутаторы?Можно просто написать:
template <class T>
void mutate(T& t)
{
t.mutate1(...);
t.mutate2(...);
t.mutate3(...);
}
Это ваш агрегатный мутатор, только это простой шаблон функции, основанный на статическом полиморфизме, а не комбинированный список мутаторов, составляющий один супермутатор.
Я один разсделал что-то, что могло бы быть довольно похожим.Я сделал функциональные объекты, которые оператор & & мог бы объединить в суперфункциональные объекты, которые применили оба операнда (в порядке слева направо), чтобы можно было написать код вроде:
foreach(v.begin(), v.end(), attack && burn && drain);
Это было действительно аккуратно ив то время мне это казалось действительно умным, и это было довольно эффективно, потому что оно генерировало новые функциональные объекты на лету (без задействованных механизмов времени выполнения), но когда мои коллеги увидели это, они подумали, что я сошел с ума.Оглядываясь назад, я пытался втиснуть все в программирование в функциональном стиле, которое имеет свою полезность, но, вероятно, не следует чрезмерно полагаться на C ++.Было бы достаточно просто написать:
BOOST_FOR_EACH(Something& something, v)
{
attack(something);
burn(something);
drain(something);
}
Конечно, это больше строк кода, но он имеет преимущество, заключающееся в том, что он централизован и прост в отладке, и не вводит инопланетные концепции другим людям, работающим с моимкод.Я обнаружил, что гораздо выгоднее вместо этого сосредоточиться на строгой логике, чем пытаться принудительно сокращать строки кода.
Я рекомендую вам глубоко задуматься над этим и по-настоящему задуматься, стоит ли продолжать этот мутатор.на основе дизайна, независимо от того, насколько он умный и жесткий.Если другие люди не могут быстро понять это, если у вас нет полномочий авторитетных авторов, убедить людей в том, что им понравится, будет сложно.
Что касается InnerMutator, я думаю, вам следует избегать этого, как чумы.,Наличие внешних классов-мутаторов, которые могут изменять внутренние элементы класса настолько напрямую, насколько это возможно, в данном случае лишает многие цели создания внутренних элементов.