设计原则 & 设计模式

最近接触了几个程序员朋友，发现对设计模式(Design Patterns)很感兴趣，这是好事。因为学习编码和面向对象一段时间以后，适当掌握和应用设计模式可以提高编码的质量，并逐步提高自己的能力，往架构方面发展。但是他们和很多人一样，其中包括我，重复走着弯路。

设计模式更多的是一种思想的实际体现，在应用的时候没必要生搬硬套，更没必要非得把二十多个设计模式强背下来。我们需要的是去理解，在设计的时候我们会经常将多个模式混合使用，或者将某个模式适当变形。总之适度就好，为了使用某个模式而让我们的代码显得臃肿和复杂是非常不明智的，因为我们最终的目的是软件本身的功能，而不是设计比赛。顺便说一下，如果你没有了解面向对象理论，那么就不要去看设计模式。

另外，和设计模式相关的另外一个词是设计原则。设计原则所知的人要少得多，但并不表示它不重要。这么说吧，设计原则更像是理论，而设计模式则是这种理论的具体体现。就像武功秘籍中的总纲和招式，只懂招式是成不了高手的。下面列出几个基本的设计原则，建议您在学习设计模式的同时去理解它。

以下文字部分摘自《敏捷软件开发》

1. SRP (单一职责原则)：就一个类而言，应该仅有一个引起它变化的原因。

这个原则实质上是对于一个类的粒度划分作出了一个规定。一个具备强大功能的庞大类并不是一个好的做法，不如将其分割成多个小类，每个小类仅提供某个单一的功能，这样我们的编码和测试都会简化，避免了因为复杂而造成潜在的错误，然后使用Facade或者Adapter模式对外提供一个聚合的操作接口就可以了。软件设计上组合和继承一样重要，非类库开发的时候推荐更多的使用组合而不是继承。

2. OCP (开放-封闭原则)：软件实体(类、模块、函数等)应该是可以扩展的，但是不可修改的。

这个原则一般通过抽象和多态来体现其机制。我们通过抽象基类或接口来提供一个标准调用规范，每个实质子类都继承或者实现这个规范以达到不同的应用操作。在实际使用中我们一般通过工厂模式(Abstract Factory / Factory Method / Simple Factory)来到到可扩展而不修改现有代码的目的。

3. LSP (里氏替换原则)：子类型必须能替换掉他们的基类型。

这个原则实质上就是多态的一种体现，子类继承或者覆盖基类的方法，具有和基类完全相同的调用规范。不过这个原则提醒我们在C#中尽可能不要使用new关键字改写基类的方法和属性，因为这样做会造成潜在的多态错误，我的blog中有一篇《 new 和 override 的区别》日志讲述了这个问题。

4. DIP (依赖倒置原则)：高层模块不应该依赖于低层模块，二者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。

高层模块一般是指那些实现业务规则的单元，而所谓低层模块是具体的一些功能代码。我们在设计的时候，一般高层模块会直接依赖于低层模块来实现其具体功能，这势必会造成相关干扰，任何一个模块的修改都会影响其关联的模块。因此DIP原则建议我们在两个模块之间添加一个抽象，两者通过依赖和实现抽象来达到沟通和调用，从而确保在抽象不变动的情况下，各自隔离而互不影响。抽象本身应该是个干净的协议，它具备完整的独立性，如果依赖于某个功能细节，那么抽象本身就变成不稳定因素，造成以后修改的污染。

5. ISP (接口隔离原则)：不应该强迫客户依赖于他们不用的方法。

很多时候我们设计的一个类会提供给多个客户调用，那么势必造成客户会“看到”一些他们根本用不上的方法，这对于客户是一种干扰，会加大他们的负担，甚至造成错误调用而影响系统的功能实现。在C#中我们可以继承多个接口，每个客户只使用其特定的接口，更具体一点，我们返回给客户的是一个接口，而不是一个类实例来达到接口隔离。在类编码中可能还会用到接口方法这个概念。

推荐2本书：

《设计模式》- 就是那本有名的GoF，机械工业出版社。
《敏捷软件开发》- 这本书介绍了敏捷开发(XP)，设计原则和设计模式。其中设计模式介绍得更通俗易懂一些，配合《设计模式》看会更好一点。清华大学出版社。