对象解耦和设计模式

不知道各位对这几个概念：封装、继承和多态是怎样理解的，也许大家都在脑海中有那么一种印象，但是每个人也都不不同的看法，我先说说我的看法：

封装，就是把对象的属性和行为包装起来，隐藏属性，公开行为。

继承，是子类和父类之间共享属性和行为的机制。

多态，是对象的消息处理机制，不同的对象接收到同一个消息可以产生完全不同的结果。

那么多的设计模式，那么多的软件架构，无非就是封装和解耦、继承和关联、多态和转型的应用。这里面，着重看一下解耦。

评价一个软件结构是否合理，耦合的强弱是很重要的一个评判因素，强耦合的系统在应对变化的时候总是感觉乏力，而一个弱耦合的系统则会轻松自如。一个系统的耦合度，包括功能耦合度、流程耦合度等，怎么样让各个功能之间的耦合度下降，怎么样让流程上下环节的耦合度下降，这都是在进行业务分析的时候做的，当前期阶段的分析都完成之后，这个系统模块之间的耦合度就基本确定了，而我们所要做的是让我们的软件能够在既定的前提下更好的应对变化，这就需要考虑到系统中对象之间的耦合度。

不谈具体业务，先看一句话：一朵红玫瑰。

很明显，在这里，它就是一个对象。但是，在深入想一下，或者对比这一句：一个骑着自行车的男人，很明显，你会认为这里有两个对象。那么，为什么要把红和玫瑰这么紧密地结合呢？我们为什么不可以把“一朵玫瑰花”也看成两个对象呢？试一下这样，将其分解为：一朵红花，它是玫瑰花。一下子就变成两个对象了。为什么非要分开成两个对象呢？看一下变化，我现在需要一支黄玫瑰。那么照第一种分析，这个对象就要变了，即：一朵黄玫瑰，而第二种分析，而只会涉及到系统的一半，即：一朵黄花，它是玫瑰花。看出来了吧，Decorator模式正适合这种情况，那就拿来用吧。（不过好像这个例子也不太妥当）

到了这里，你可能会说，哦，解耦就是把一个东西拆为几部分。不错，不过，这只是开始。当你能够把对象按照粗细力度分析建模之后，下面就开始编码了，假如你的系统需要打印功能，但是现在流行的打印控件有很多，老板告诉你不能够把打印功能和你所用的控件紧密连到一起，也就是说你需要解耦。好了，怎样做呢？Adapter和Bridge模式会帮助你。Adapter模式可以将不同的打印API统一为你想要的接口，Bridge模式可以把打印功能抽象出来的接口和具体打印控件的实现分离，这样子就在很大程度上把打印功能和需要的具体控件解耦了。

合理的解耦可以提高系统的健壮性，也就是所谓的高内聚、低耦合，但是完全的解耦是不存在的，只要能够应对预期范围内的变化，解耦就是成功的。

在进行封装和解耦的过程中，需要对设计和代码不断的进行重构，而你所进行的重构的最终成果物也许就是某个模式。所以说，模式并不是什么高深的东西，而是在实际的分析过程中，在对系统的不断重构中，发现用这样的一种结构能够很好的应对某些问题，那么，这个时候，你就翻翻设计模式，可能你所设计的结构就是某个模式呢