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

Question

I am trying to figure out what this design pattern is. I used it often when I have common logic that needs to execute on/for a single object.

I am thinking maybe Facade ?

Eg Validation

A public interface

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

Multiple implementations

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) { } }

And then a class takes either a IValidatorCollection or straight IEnumerable<IValidator> which injects all registered validators.

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);
        }
    }
}

EDIT

I know this uses IoC/DI to inject the collection of IValidator<T> but that is not the pattern I am looking for. Its the pattern that you hide multiple implementations of an interface behind a single interface / class

Answer 1

The example you've given is a good example of the Strategy pattern .

Both the implementers of the Validator strategy and the users of the Validator depend on the abstraction IValidator.

This keeps the Validation users from caring about the details of particular Validation operations.

This also keeps the Validation implementers from caring about how or when a given Validation is performed.

Edit: In fact, under the wiki entry for strategy pattern it explicitly mentions Validation:

For instance, a class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed. The validation strategies, encapsulated separately from the validating object, may be used by other validating objects in different areas of the system (or even different systems) without code duplication.

Answer 2

The closest match imho is actually bridge pattern, but not really. You're decoupling the validation rules/logic from the Validate method. While clients rely on the Validate method, you can actually modify the rules dynamically, based on some kind of criteria.

I've written such code before, albeit a little bit more complicated (eg the order of validation rules can be configured dynamically), I wouldn't personally classify it as any pattern. You're simple using dependency injection to decouple the validation rules from the actual validation process.

That said, I don't like the injection of list validations. You might want to consider refactoring it into strategy pattern (eg ValidationStrategy ), and move the Validate method into there instead. Right now, most of your controllers get this "long" type, which is not that readable, plus, you'd have to duplicate the "Validate" method to each controller, or move it to base class (which I don't think is correct place).

Ps, to me your current solution does not look like strategy. Maybe "implementation wise", but the point is to get the intent right, as some of the patterns are implemented quite similarly anyways, but differ in their intent.