设计原则3： 不要和陌生人说话.

  

解释：该原则主要用于解决模块之间的紧耦合问题。

在很多的系统架构中经常会看到如下的结构 ：

这种结构在程序中我们经常见到，例如在Java程序中在类文件中一堆的Import 语句，

或在Delphi程序中Uses后面跟一堆的东东,这些都是紧耦合的表现.

这种结构的缺点是，如果随着业务的发展，假设要替换程序中的类ClassB或ClassB中的某个方法, 那么我们要修改程序中所有的类，这是一项很庞大和结果不可预料的过程，很多的Bug都是在这种修改中产生的。

 

我们在程序中采用不要和陌生人说话原则后的结构：

 

在原结构中我们增加了一个大家都熟悉的Class 即ClassManager, 这个我们都熟悉的人物，

为了说明这个类的作用，我们可以举一个现实生活中的例子。

这个ClassManager有点像部门或公司的秘书，或者一个家庭中的管家。 有了秘书老板出差就不用自己定机票了，他就不用了解去那里订票了，那里会比较便宜，那个航空公司的服务会比较好，航空公司的服务电话是否有变化，是否有新的更好的航空公司出来，这些老板都不需要了解了，只要老板一句话，秘书一定会定一张最符合要求的机票递到老板手上。对于老板来说，有了秘书，整个世界都清静了。

对于部门员工来说，有了秘书办事也方便了，假设我们要找老板聊聊天，我们只要跟秘书说一声秘书要想跟老板聊两句，秘书就会给你安排时间，安排会议室，然后通知你，就这么简单。 如果没有秘书，我们可能还要关心老板最近有没有出差呀，老板最近心情怎么样啊，我是否要找个更合适的时间跟老板聊聊啊等等。。。， 有了秘书这些都不用了，秘书是最了解老板的人，也是最了解你的人，一切他都会给你安排好的。

 

这个ClassManager也有点像富人家的管家，为什么管家这个职业历经几个世纪都不会消失呢，其中自然有他的好处说在。

例如富家老爷想吃红烧肉，只要吩咐管家，马上就能到嘴边，哪天要次热干面，鸭脖子，桂林米粉,肉夹馍，鲍鱼鱼翅 ，他只要跟管家说就行了，管家会为他安排好，这些东西有可能是自己家做的，有可能是超市买的，有可能空运过来的，老爷都不用去了解。 同时家里厨子走在大街上他都可能不认识，虽然厨子每天都给他做吃的，厨子也可能不认识他，他只知道有人给他开工资，这个人是什么口味，他不用知道这人长什么样。那天厨子换了，老爷也是没感觉的，应为这两个对象是没有关联关系的。这种关系在现实中虽然有些冷酷，但是在系统中是相当有好处的。

 

在这种结构我们可以用很多的设计模式来达到最佳的效果。

1．  在ClassManager中使用类工厂模式ClassA ,B,C,D,E,F,G都由ClassManager来创建，将结果提升为抽象类或接口的方式反馈给使用者。

2．  使用代理模式，将请求的任务委托给代理类来处理。

3．  使用缓冲池模式，当业务很忙时可以多生成几个对象处理。

等等。

 

万事万物都有它的缺点。

这种结构也有它本身的弱点，在该结构中我们ClassManager 处于中心位置，大家都知道城市的中心路段是会经常堵车的，同样ClassManager有时会成为性能的瓶颈，因为有太多的对象依赖于它。 但是有矛必有盾，我们可以采用多线程技术解决响应速度问题，同步互斥解决资源争用问题。