大家一起学面向对象设计模式系列Chapter 02 软件设计的基本原则
我们为什么要使用设计模式呢？有人可能会说为了设计出"高内聚低耦合"的软件。"高内聚低耦合"的软件实际上也就是本文所说的具有可维护性和可复用性的软件。
这篇文章主要讲解两方面内容，这两方面是软件设计中很重要，也是很关键的内容，希望大家认真思考并深刻理解。第一部分就是关于软件的可维护性和可复用性的相关内容，第二部分就是在第一部分的基础上逐条讲解面向对象软件设计的基本原则，本文内容都是些很理论性的东西，这些理论是软件设计的基础。凡是有理论的地方，就有如何恰当的将理论应用到实践中去的问题，设计模式是对于学习OO设计原则的具体指导，也就是说设计模式就是将这些理论应用到实践的一种成熟的方式。
软件的可维护性和可复用性
首先来上一段大师所说的话，很经典。
“通常认为，一个易于维护的系统，就是复用率较高的系统；而一个复用率较高的系统，就是一个易于维护的系统。但是实际上，可维护性和可复用性是两个独立的目标，就像两只奔跑的兔子一样，并不总是方向一致的。对于面向对象的软件系统设计来说，在支持可维护性（Maintainability）的同时，提高系统的可复用性（Reuseability）是一个核心的问题。”－－《Java与模式》阎宏博士
软件系统的可维护性：
软件维护就是软件的再生。一个好的软件设计，必须能够允许新的设计要求以比较容易和平稳的方式加入到已有的系统中去，从而使这个系统能够不断的的焕发出活力。一个可维护性较好的系统，应当允许维护工作能够以容易、准确、安全和经济的形式进行。
【导致可维护性较低的原因】
1、过于僵硬：在系统中加入一个新的功能，不管大小都很难，不仅意味着建造一个独立的新的模块，而且因为这个新功能会波及很多其他模块，最后成跨越几个模块的改动。
2、过于脆弱：与软件的过于僵硬同时存在，是软件系统在修改已有代码时过于脆弱。对一个地方的修改，往往会导致看上去没有什么关系的另外一个地方发生故障。
3、复用率低：所谓复用，就是指一个软件的组成部分，可以在同一个项目的不同地方甚至另一个项目中重复使用。复用率低，指当一段代码，函数，模块的功能可以在新的模块或新的系统使用，但是已有代码依赖于其他很多东西，很难分开。
4、黏度过高：一个改动可以保存原始设计意图和原始设计框架的方式进行，也可以以破坏原始意图和框架进行。第一种方法对系统的未来有利，第二种办法是权宜之计，可以解决短期的问题，但是会牺牲中长期的利益。如果一个系统中使用第二种方法比使用第一种方法容易，那么就是黏度过高。
【设计的目标】
1、可扩展性：新的性能可以很容易地加入到系统中去，就是可扩展性。这就是系统“过于僵硬”的属性的方面。
2、灵活性：可以允许代码修改平稳地发生，而不会波及到很多其他的模块，这就是灵活性。灵活性其实就是“过于脆弱”的属性的方面。
3、可插入性：可以很容易地将一个类抽出去，同时将另外一个有同样接口的类加入进来，这就是可插入性。其实，这就是“黏度过高”的方面。
软件系统的可复用性：
【软件复用的好处】
1、较高的生产效率；
2、较高的软件质量；
3、恰当使用复用可以改善系统的可维护性。
【传统的复用形式】
1、代码的剪贴复用；
2、算法的复用；
3、数据结构的复用。
【面向对象设计的复用】
在面向对象语言中，数据的抽象化，继承，封装和多态性使得一个系统可以在更高层次上提供可复用性。数据的抽象化和继承关系使得概念和定义可以复用；多态性使得实现和应用得到复用；而抽象化和封装可以保持和促进系统的可维护性，复用的重点转移到含有宏观商业逻辑的抽象层次上。在面向对象的设计里面，可维护性复用是以设计原则和设计模式为基础的。
提高系统可维护性和可复用性的设计原则
1、“开－闭”原则(Open-Closed Principle，或者OCP)；
一个软件实体应该对扩展开放，对修改关闭；
在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展。换言之，应当可以在不必修改源代码的情况下改变这个模块的行为。这个原则实际上是对“对可变性的封闭原则“：找到一个系统的可变因素，将之封装起来。这个原则意昧着两点：
1) 一个可变性不应当散落在代码的很多角落里，而应当被封装到一个对象里面。同一种可变性的不同表象意昧着同一个继承等级结构中的具体子类。
继承就当被看作是封装变化的方法，而不应当被认为是从一般的对象生成特殊对象的方法。
2) 一种可变性不应当与另一种可变性混合在一起。（所有类图的继承结构一般不会超过两层，不然就意昧着将两种不同的可变性混合在了一起。）
这个原则是总的原则，其它几条是这个原则的手段和工具。
2、里氏替代原则(Liskov Substitution Principle，或者LSP)；
如果对于每一个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有变化，那么类型T2是类型T1的子类型。
换言之，一个软件实体如果使用的是一个基类的话，那么一定适用于其子类，而且它根本不能察觉出基类对象和子类对象的区别。
反过来代换不成立。
3、依赖倒转原则(Dependency Inversion Principle，或者DIP)；
要依赖于抽象，不要依赖于具体。
开闭原则是目标，而达到这一目标的手段是依赖倒转原则。
抽象层次包含的是应用系统的商务逻辑和宏观的、对整个系统来说重要的战略性决定，是必然性的体现，那么抽象层次就应当是较为稳定的，应当是复用的重点；也应当是维护的重点；而具体层次则含有一些次要的与实现有关的算法和逻辑，以及战术性的决定，带有相当大的偶然性选择。具体层次的代码是会经常有变动的，不能避免出现错误。
4、接口隔离原则(Interface Segregation Principle，或者ISP)；
使用多个专门的接口比使用单一的总接口要好。
换言之，从一个客户类的角度讲：一个类对另一个类的依赖性应当是建立在最小的接口上的。
接口隔离原则与迪米特法则（下面讲到）都是对一个软件实体与其他的软件实体的通信限制。迪米特原则要求尽可能地限制通信的宽度和深度，接品隔离原则要求通信的宽度尽可能地窄。这样做的结果使一个软件系统在功能扩展过程当中，不会将修改的压力传递到其他对象。
一个接口相当于剧本中的一种角色，而此角色在一个舞台上由哪一个演员来演则相当于接口的实现。因此，一个接口应当简单地代表一个角色，而不是多个角色。如果系统涉及到多个角色的话，那么每一个角色都应当由一个特定的接口代表。
5、组合/聚合复用原则(Composition/Aggregation Principle，或者CARP)；
组合/聚合原则就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到得复用已有功能的目的。
要尽量使用组合/聚合，尽量不要使用继承。
6、迪米特法则(Law of Demeter，或者LoD)；
一个软件实体应当尽可能少的与其他实体发生相互作用。模块之间的交互要少。这样做的结果是当系统的功能需要扩展时，会相对更容易地做到对修改的关闭。
一个对象应当对其他对象有尽可能少的了解。
7、单一职责原则（Single Responsibility Principle，或者SRP）
在设计中为每种职责设计一个类，彼此保持正交，互不干涉。这个原则比较容易理解，这里不在多说。
小结
当我们掌握了C#的语法，当我们了解了面向对象的封装、继承、多态等特性，当我们可以用各种框架与技术构建桌面以及Web应用时，这并不意味着我们可以写出面向对象的程序，不意味着我们可以很好的实现代码复用，弹性维护，不意味着我们可以实现在维护、扩展基础上的代码复用。使用面向对象语言开发的程序不一定是面向对象的，使用面向过程的语言开发的程序也不一定不是面向对象的。要想开发出一个具有可维护性和可复用性的软件系统，那是需要优秀的设计和长时间的运行才能完成的，其实我们可以观察一下，任何一个优秀的软件产品都是经过长时间的设计，运行，维护，修改等最后才成为成功的产品，版本上也在不断的更新。衡量一个软件开发者是不是一个好的软件开发者，不是看他是否实现了软件的必要功能，而是要看你的软件在满足功能需求的情况下是否做到了复用性和可扩展性，这对于一个大型系统尤其重要。我们不要静止的看待一个软件，而一定要把软件过程放在时间轴上来观察与设计它，只有放在时间轴上经得住考验的软件系统才是成功的。软件的复用性和可扩展性对于大型系统是必要的，我们在设计自己的软件系统时，甚至在编写代码时更需要考虑一下这样做是否遵循了系统设计的原则，是否有利于系统的可维护性和可复用性，是否达到了常说的“高内聚低耦合”呢？设计模式正是解决这一问题的王道。
从下文开始我们将结合实例对于GoF23种设计模式进行一一讲解。
Welcome to share your idea,thank you!欢迎分享您的想法,谢谢!