C++程序设计题

Question

在我最近参与的几个项目中，我几乎沉迷于以下编码模式:(我不确定是否有合适的名称，但无论如何...)

假设某个对象处于某种确定状态，我们不想从外部更改此状态。这些更改可能意味着任何行为，可能会调用任何算法，但事实是它们专注于更改某些对象的状态(成员状态、数据状态等...)。

让我们将一种改变这些对象的离散方式称为 Mutator。 Mutators (通常) 应用一次，它们有一些内部方法，如 apply(Target& target, ...)，它会立即引发更改对象的状态(事实上，它们是某种功能对象)。

它们也可以很容易地融入链并逐一应用(Mutator m1, m2, ...)；它们还可以使用 virtual void apply(...) 方法从一些基本的 BasicMutator 派生。

我引入了名为 InnerMutator 和 ExplicitMutator 的类，它们在访问方面有所不同 - 首先，它们还可以更改 内部状态对象并应声明为友元(friend InnerMutator::access;)。

---

在这些项目中，我的逻辑按以下方式工作:

1. 准备可用的突变体，选择要应用的突变体
2. 创建对象并将其设置为某个确定的状态
3. foreach (mutator) mutator.apply(object);

现在是问题。

This scheme turnes to work well and (to me) seems as a sample of some non-standard but useful design pattern.

What makes me feel uncomfortable is that InnerMutator stuff. I don't think declaring mutator a friend to every object which state could be changed is a good idea and I wan't to find the appropriate alternative.

Could this situation be solved in terms of Mutators or could you advice some alternative pattern with the same result?

谢谢。

Answer 1

我希望这不会被冒犯，但我不禁认为这种设计对于一个相当简单的问题来说是一个过于花哨的解决方案。

例如，为什么需要聚合突变体？一个人只能写:

template <class T>
void mutate(T& t)
{
    t.mutate1(...);
    t.mutate2(...);
    t.mutate3(...);
}

这就是聚合变元，只是它是一个简单的函数模板，它依赖于静态多态性，而不是构成一个 super 变元的变元组合列表。

我曾经做过一些可能非常相似的事情。我制作了可以由运算符 && 组合成应用两个操作数(从左到右的顺序)的 super 函数对象的函数对象，这样就可以编写如下代码:

foreach(v.begin(), v.end(), attack && burn && drain);

它真的很简洁，当时对我来说真的很聪明，而且非常高效，因为它可以动态生成新的函数对象(不涉及运行时机制)，但是当我的同事看到它时，他们认为我是疯狂的。回想起来，我曾试图将所有东西都塞进函数式编程中，这有它的用处，但在 C++ 中可能不应该过度依赖。写起来很容易:

BOOST_FOR_EACH(Something& something, v)
{
    attack(something);
    burn(something);
    drain(something);
}

虽然它有更多的代码行，但它具有集中化和易于调试的优点，并且不会向使用我的代码的其他人引入陌生的概念。我发现专注于严密的逻辑比试图强行减少代码行更有益。

我建议您对此进行深入思考，并认真考虑是否值得继续使用这种基于更改器(mutator)的设计，无论它多么聪明和紧凑。如果其他人不能快速理解它，除非你有 boost 作者的权限，否则很难说服人们喜欢它。

至于 InnerMutator，我认为您应该像躲避瘟疫一样避开它。拥有可以像在这里一样直接修改类的内部结构的外部修改器类完全违背了拥有内部结构的很多目的。