这是立面模式吗？ 如果没有，那又如何？

Question

我试图弄清楚这种设计模式是什么。 当我具有需要在单个对象上执行/为单个对象执行的通用逻辑时，经常使用它。

我在想Facade吗？

例如Validation

公共接口

public interface IValidator<T>
{
    void Validate(T obj);
}

多种实现

public class CodeValidator<T> : IValidator<T> { public void Validate(T obj) { } }
public class PerfValidator<T> : IValidator<T> { public void Validate(T obj) { } }
public class DotValidator<T> : IValidator<T> { public void Validate(T obj) { } }
public class NetfValidator<T> : IValidator<T> { public void Validate(T obj) { } }

然后，一个类采用IValidatorCollection或直接的IEnumerable<IValidator> ，后者将注入所有已注册的验证器。

public class PostValidaitonController
{
    private IEnumerable<IValidator<Post>> _validators;

    public PostValidaitonController(IEnumerable<IValidator<Post>> validators)
    {
        _validators = validators;
    }

    public void Validate(Post post)
    {
        foreach (var validator in _validators)
        {
            validator.Validate(post);
        }
    }
}

编辑

我知道这使用IoC / DI注入IValidator<T>的集合， IValidator<T>不是我要寻找的模式。 它是在单个interface / class后面隐藏interface多个实现的模式

Answer 1

您所提供的示例是Strategy模式的一个很好的示例。

验证者策略的实施者和验证者的用户都依赖于抽象IValidator。

这使Validation用户不必关心特定Validation操作的细节。

这也使验证实施者不必关心如何或何时执行给定的验证。

编辑：实际上，在策略模式的Wiki条目下，它明确提到了Validation：

例如，对传入数据执行验证的类可以使用策略模式基于数据类型，数据源，用户选择或其他区分因素来选择验证算法。 在每种情况下，直到运行时，这些因素都是未知的，并且可能需要进行根本不同的验证。 与验证对象分开封装的验证策略可以由系统（甚至不同系统）不同区域中的其他验证对象使用，而无需代码重复。

Answer 2

最接近的匹配恕我直言实际上是桥接模式，但实际上不是。 您正在将验证规则/逻辑与Validate方法脱钩。 当客户端依靠Validate方法时，您实际上可以根据某种标准动态修改规则。

我之前写过这样的代码，尽管稍微复杂一点（例如，验证规则的顺序可以动态配置），但我个人不会将其归类为任何模式。 您很容易使用依赖项注入将验证规则与实际验证过程脱钩。

就是说，我不喜欢注入列表验证。 您可能需要考虑将其重构为策略模式（例如ValidationStrategy ），然后将Validate方法移到其中。 现在，您的大多数控制器都获得了这种“长”类型，这种类型的可读性不高，此外，您必须将“ Validate”方法复制到每个控制器，或者将其移至基类（我认为这不是。）是正确的地方）。

附言：对我来说，您当前的解决方案看起来不像策略。 也许是“明智的实现”，但重点是要正确实现意图，因为无论如何，某些模式的实现都非常相似，但意图不同。