我注意到很多开发人员定义了将使用DI框架注入的EVERY类的接口。为每个类定义接口有哪些优点？
让你的应用程序组件(包含应用程序逻辑的类)实现一个接口是很重要的，因为这提出了以下概念：
原文链接：https://www.f2er.com/javaschema/282096.htmlProgram to an interface,not an implementation.
这实际上是Dependency Inversion Principle.这样做允许您替换，拦截或装饰依赖关系，而不需要更改这种依赖关系的消费者。
在许多情况下，开发人员将违反SOLID原则，但是在类和接口之间进行几乎一对一的映射。几乎肯定违反的原则之一是@L_301_2@，因为当每个类都有自己的接口时，不可能扩展(装饰)一组具有交叉关切的类(没有拦截欺骗)。
在我写的系统中，我定义了两个通用接口，涵盖业务层的大部分代码。它们被称为ICommandHandler< TCommand>和一个IQueryHandler< TQuery，TResult> ;:::
public interface ICommandHandler<TCommand>
{
void Handle(TCommand command);
}
public interface IQueryHandler<TQuery,TResult> where TQuery : IQuery<TResult>
{
TResult Handle(TQuery query);
}
除了不必定义许多接口的良好的副作用，这样可以很好的灵活性和易于测试。您可以阅读更多关于它here和here。
根据我写的系统，我也可以使用以下界面：
> IValidator< T>用于验证消息
> ISecurityValidator< T>用于对消息应用安全限制
存储库模式
> IAuthorizationFilter< T>用于对IQueryable< T>应用授权/安全过滤查询。
根据我写的系统，80％到98％之间的所有组件都可以实现我定义的这些通用接口之一。这使得将交叉问题应用于所谓的joinpoints之类的问题。
