粉色的网站百度云盘资源搜索

        开了很多人写的程序，都适用了接口，也适用了注入，也没有感到什么不妥。如果只是为了注入而写接口，其实我感觉大可不必，特别是把接口和实体写在一个项目项目中的。

        我不知道其他人怎么看接口这一层，接口最大的特性，在使用的时候不需要做强转换，例如：

        public interface interfaceA : interfaceBase

        {

                void actionA();

        }

        public interface interfaceB:interfaceA

        {

                void actionB();

        }

当一个实现类实现了interfaceB

        public class classB : interfaceB{}

在使用的时候，interfaceA cls = new classB();

这样的赋值是不会有问题的，但是不能在直接在代码中写cls.actionB();因为A中并没有B的方法定义。

        常常注入，都只是放了一个接口定义，注入框架就能把实体注入进去，如果：

        public class classC : interfaceB{}

        多了一个classC的实体类，那么注入是否会成功呢？其实我很好奇，没试过，好像也没这么闲去试，估计是不成功的。为什么没有试？因为我的框架的注入程序是我自己写的，我自己写的我知道，那是肯定是注入不成功的，因为我不知道要实例那个类。

        但是，如果是加载插件呢？且插件有多重，但是使用的时候只用其中一种呢？

        例如ORM的选择，我们可以定义一个IDBContext，然后有多种数据库支持方式，分别编写一套代码，例如MssqlDBContext,MysqlDBContext,OracleDBContext,SqliteDBContext,MongoDBContext,ESDBContext等等，都是实现了接口IDBContext,在使用不同数据库的时候，只要放对应不同数据库的实体类文件到系统中即可，动态加载实体类文件，后续部署就非常轻松了，不管使用什么数据库,都是遵守接口定义标准，理论上是可以任意切换数据库的，这个时候业务层和数据层已经分离开了。

        例如Redis插件的使用，可以用CSRedis,ServiceStack.Redis,项目开发可能会使用不同的插件，那么可以开发一个IRedisHelper接口，实现类都实现这个接口就可以了。

        MQ也是这样，可能使用RocketMQ,RabbitMQ或者其他，他们的使用方法是完全不同的，但是没有关系，开发一个IMQHelper接口就好了，把不同MQ操作都抽象起来，制定一套操作规则即可。

        接口除了能够支持多选插件之外，还可以作为程序扩展的一个很重要的方法。我们在写一些复杂业务的时候，可能会出现很多分支，往往程序员会把这些分支使用if或者switch来跳转到对应的方法，其实也是可以通过接口实现的。只要定义一个加载规则，不同的逻辑或者分支分别编译成一个DLL文件，切里边定义的类都实现一个接口。这样根据加载规则，动态加载对应的DLL，就能完成对应的业务处理，且这样还可以无限制扩展这样的处理方法，是一个很好的解决各种个性化需求的解决方案，同样也简化了程序的复杂度，毕竟这里没有了if或者switch之类的条件跳转。

        我在做IOT的时候，就大量使用了上述方法，例如大屏数据的动态运算、设备数据结构的解析、不同数据来源的接收器接入等。在开发框架中的Starter也是这样的一个原理，允许在框架启动的时候加载各种插件，例如MQStart:IStarter.

        灵活使用好接口，对程序实现和扩展是非常有用的，往往能解决很多麻烦的交叉问题，让事情变得更加单纯，毕竟不在一个DLL中，互相就没有了干扰，开发的时候也有了约束。而对于程序的控制和迭代，也能起到很重要的作用。不要怕麻烦写多一层接口，接口也是很好体现面向对象抽象的思维，找共性分实现，求同存异。可能还有更好的应用，我没有接触到，这里抛砖引玉吧，希望能够积累更多的技巧和经验。