浅谈解耦的意义---我们一直追求解耦，却不知道她哪里好

谈到解耦，就要提到设计模式，设计模式来源于分析模式，设计模式是分析模式的具体现话。 举个例子，我们购买一个大件，像冰箱。

从客观的角度分析，这种东西不是我们直接拿走的，那么我们简化这个流程就是：你选择冰箱，给钱，然后营业员给你生成订单，送货人发货。如果说我们把选择冰箱，下单付款，送货期间作为粉色的时间，然后，我中间牵扯到的营业员，送货人，客户这类的参与者作为绿色，最后中间的权限例如业务员收钱的时候，从数据考虑，他是操作财务表的权限，订单是操作订单表的权限，这部分权限作为黄色，在领域模型中，在客观世界中是绿色赋予了黄色在粉色期间执行操作。客观总结起来就是指定人，拥有指定权限，做指定的操作

从三层的角度分析，我们是有数据表的，用户表，订单表，送货表等等，在数据层和业务层到底分离的是什么，还是这个购物的例子，打个不恰当的比方：业务员收钱，为其生成订单，实际上就是在操作数据，那么数据层拿走了这部分的工作。剩下的工作是，业务员哪儿来的收钱和操作财务权限？业务员怎么知道是谁要购买（谁是参与者）？这些就交给了逻辑层。

将不同的职责封装到不同的类或者模块中，不正是面向对象的基本原则之一吗（单一职责原则）。但我们使用抽象工厂的设计模式时，降低了数据层和逻辑层之间的依赖关系，创建对象依赖于工厂类和一套抽象接口，依赖倒置的核心思想就是抽象。上层模块调用接口，下层模块实现接口。

说到这里是解耦的过程，那么解耦的意义呢？

就像我们开发过程中一个人，从前台到后台到维护，到数据库全管，就不如分工合作，内部的联系越少，一个系统就越稳定，俗话说，多一个事不如少一事。还是用实际的来说话：业务是会变化的，但是操作数据库，终归是那些方法，业务改变的时候，我们无需改变数据层。即使需要新的数据层方法，也只是添加一个方法，无需改变业务层的旧代码。刚才我们所说的又好像是分工的好处？其实来说，三层本身就是一个解耦的架构，三层的本身也是为可扩展性而生的，只是我们还需要继续使用各种模式解耦，我们只能无限降低耦合度，但并不能根除，因为彼此失去了关联就是去了意义。开放封闭原则说道：软件实体（类，模块，方法等）应该是可扩展的，意思是软件模块的功能可以变化，但是在拓展新功能的同时，不需要修改原有代码，更不会影响到原有代码。怎么能做到开放和封闭呢？还是抽象。抽象的东西是稳定的，通常不需要修改，抽象的东西可以具体化为不同的实例，实现扩展。

中国梦就是个很好的面向对象设计。

中国梦可拓展：它可以拓展为农民的中国梦（拥有自己的土地），商人的中国梦（生意兴隆等），运动员的中国梦（成为冠军）

中国梦很稳定：虽然梦想千差万别，但最终都可以归于不变的中国梦。梦想的基类永不变。

2015-7-18补充

在团队开发中，在无需过多了解其它层次的基础上，可以将某一层作为一个有机的整体来理解，例如无需知道以太网的工作细节，照样可以再TCP上构建FTP服务。

【摘抄自---企业应用架构模式】

一旦构建好某一层次，就可以用它为很多上层服务提供支持。因此，TCP/ip同时被FTP,telnet,SSH,HTTP使用。否则，所有这些高层协议都必须编写他们各自的底层协议。

【摘抄自---企业应用架构模式】