设计模式学习笔记(二)：模式、设计与复杂性

模式与设计的关系

每个模式 都描述了某个特定场景中 一个特定问题的约束因素 / 动机和关系，并为设计者提供一种解决这些问题的优雅方案 。换句话说，模式仅仅是描述了特定场景下的关系和约束因素 ，正因如此，模式本身并不是最重要的，特定场景下的关系和约束因素才是最真实的 ，而模式仅仅是提供了一组描述这些关系的一组词汇，提供了一套解决这些关系的优雅方式而已。

 

在软件设计中，模式是随特定场景下的关系和约束因素而定的 。也就是说，对所要解决问题的分析和理解是使用模式的必要条件。只有清楚了特定场景下的关系和约束因素，才能很好地选择解决问题的方法和适用的模式。

 

特定模式描述的是问题中概念 ( 抽象类 ) 之间的关系 ，比如所有的行为模式， bridge 模式等；或者是抽象类和派生类之间的关系 ，比如 Proxy ， Composite ， Decorator 等；抑或是新类和原有类之间的关系， 如 Adaptor ， Facade 等。这些关系未必是显而易见的，它们都是问题分析的结果。没有从概念视角对问题的分析，这些关系是不能凸现出来的。因此，使用模式应该建立在共性与可变分析、分析矩阵等方法的基础上。 在概念视角层次 上的分析，往往考虑的是抽象类之间的关系 ，因此这时所采用的模式一般是行为模式、 bridge 模式等 。描述抽象类和派生类之间关系的模式一般应该等到实现层次时才考虑引入。这种分层设计有助于简化设计过程，忽略不必要的次要因素，产生更好的高层设计。

 

根据上述观点，虽然模式经常是组合使用 ，但模式的使用顺序 是有先后之分的。在高层设计会采用一些高层的主模式，在代码实现级别上，也会再次引入其他合适的模式。个人觉得行为模式、 Bridge 、 Facade 等模式是最常用的主模式。

 

模式与继承

（这里仅针对静态语言，在动态语言中，多态并非通过继承实现）

封装 / 继承 / 多态都是面向对象的基本概念。前面已经讲过，封装变化是模式的核心思想之一。同时，从抽象类和派生类的角度看，继承和多态使得抽象类能够封装派生类的类型 。显然，继承和多态使类封装变化成为可能 。因此，在设计模式中，继承是随处可见的。

从模式角度看，模式是面向对象复用的基础元素。采用模式可使设计的软件更加灵活，更易扩展，更易维护，这也正是 OCP( 开放封闭原则 ) 所强调的。要实现这个目标，继承也是必不可少的。继承使派生类之间可互相替换 ，因此也就封装了抽象类背后的变化。

一般来说，使用模式是有代价的。模式虽有其自身的优越性，但只有在问题本身有一定的复杂性时，采用模式来简化这些复杂性才是有意义的。然而，不能忽略的是：模式本身 ( 所涉及的相互交互的类 ) 是有一定复杂性的 。每个模式中相互交互的类之间，可以说是紧密耦合在一起的。这些类基本上是不可分的，它们本身就是作为一个整体而存在。同时这些类背后的继承关系在使模式灵活的同时，也增加了复杂性。这都是使用模式时需要考虑的因素。切记 : 模式中的类是作为一个整体而存在，它们是紧密耦合的关系；模式描述了这些类之间的关系和约束因素，丰富设计词汇，使我们容易交流，但同时要清楚实现时是对这些类和这些交互关系的再现。

 

待续......