对于解耦的理解

以三层为例子：

在Bll层中创建Dal层的某个对象

IUserDal userDal = DalAbstractFactory.CreateUserDal();

即层之间的关联降到最低，这样我们很容易想到引用一个第三方来作为中间介质。

这就引出了接口，在层中要创建其他层的某个对象时，用接口来接收这个对象，（这个接口是这个对象的接口，如对象为UserDal，接口为IUserDal）

这就实现了等式左边与Dal层的解耦，关于右边，我们不能直接创建该对象的实例。这样还是耦合，所以引入工厂的概念，

实质还是通过一个第三方来帮我们进行这个动作，即创建对象。

这样就实现了等式两边均解耦。

但回过头来想，解耦的目的是什么？

不就是为了降低代码的维护成本与可读性吗，可读性先放在一边。

那么两层之间是解耦了，但在工厂中是直接创建对象的，虽然代码很少，只是创建对象，但项目一大，有很多对象，依然维护起来很麻烦。

我们想，有个什么办法把工厂里创建对象这个动作也给封装下呢，使到时候要修改的时候，修改一小块地方就可以了。

于是，我们想到了利用配置文件

将对象所属的程序集（dll）与命名空间放在配置文件的appSettings节点中，

然后利用反射（Assembly）来加载程序集，与创建对象。

其实就是将我们本来在工厂中手动的两动作（添加dll引用+new一个对象）变成了动态的了。

我们将这个工厂模式称为抽象工厂。

 

小结：

　　解耦，说白了就是当用户的需求发生变化时，作为一线劳动力的我们，为自己在维护代码时省麻烦，于是在一开始设计框架的时候，设计的好一点，这个好估计是当初那么一代代程序员掉坑爬出来后的精神感悟吧。

然后再关注下代码本身，将面向对象的特性展现了一大部分。即继承，封装，多态。这里只是一小部分，框架的建设就是围绕这个特性展开的。不过有一点是这样的，个人的一点体会：不是为了用到这些特性，将他们放到框架中，

而是为了更好的框架建立，而需要用到这些特性，所以才有了这些特性，才被我们在使用。

 

有什么不合适之处请大伙儿指出，共同进步。

转载于:https://www.cnblogs.com/joeymary/p/5151202.html