Question

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

我在想 Facade ？

E.g。 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>的集合，但这不是我想要的模式。它是隐藏单interface / interface

背后class的多个实现的模式

Answer 1

您提供的示例是策略模式的一个很好的示例。

Validator策略的实现者和Validator的用户都依赖于抽象IValidator。

这使验证用户无需关心特定验证操作的详细信息。

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

编辑：事实上，在策略模式的wiki条目下，它明确提到了验证：

例如，可以对传入数据执行验证的类使用策略模式选择基于的验证算法数据类型，数据来源，用户选择或其他歧视因素。每种情况都不知道这些因素直到运行时，可能需要完全不同的验证执行。验证策略，单独封装验证对象，可以由其他验证对象使用系统的不同区域（甚至不同的系统）没有代码重复。

Answer 2

最接近的匹配imho实际上是bridge模式，但不是真的。您正在将验证规则/逻辑与Validate方法分离。虽然客户端依赖于Validate方法，但您实际上可以根据某种标准动态修改规则。

我之前编写过这样的代码，虽然有点复杂（例如，验证规则的顺序可以动态配置），但我不会将其作为任何模式进行个人分类。您可以使用依赖注入将验证规则与实际验证过程分离。

那就是说，我不喜欢注入列表验证。您可能需要考虑将其重构为策略模式（例如ValidationStrategy），并将Validate方法移到那里。现在，你的大多数控制器得到了这个＆＃34; long＆＃34;类型，这是不可读的，此外，您必须复制＆＃34;验证＆＃34;每个控制器的方法，或将其移动到基类（我不认为是正确的位置）。

Ps，对我来说，你目前的解决方案看起来并不像策略。也许＆＃34;实施明智＆＃34;，但重点是让意图正确，因为一些模式无论如何都实现得非常相似，但他们的意图不同。

这是Facade模式吗？如果不是那么什么？

2 个答案: