第2章 模式、设计原则和方法
在软件世界中，我们在不断地解决着各种问题，其中有些问题前人已经总结出了解决的方法和经验，而这些方法和经验则形成了我们所熟知的模式。本章主要讲述在面向对象设计中可以采用的一些设计模式、设计原则，以及企业架构模式。在开发过程中，如果正确采用了模式和原则，可以快速解决和分解复杂的问题，从而开发出更加漂亮的软件系统。
本章涉及的内容非常多，比如设计原则、设计模式、企业应用架构模式和软件设计方法等，而且这些内容都是软件开发与设计中的重点和难点，每一点都足够写一本厚厚的专著。本书的目的不是要详细讲解这些内容，而是要在它们的基础上讲解如何正确地进行软件的架构与设计。
阅读本书的大部分读者可能对上面这些知识都有一定程度的了解，为了方便那些还不太了解的读者能顺利阅读本书后面的内容，本章将首先会快速介绍软件的设计原则和设计模式，以便为学习后续的内容打下基础，同时会在实战案例中详细地阐述设计模式的思想，希望能引导大家真正地领悟设计模式，之后再系统地介绍了企业应用架构模式和常用的软件设计方法。
通过本章的学习，基础还不太好的读者将会对软件的设计原则、模式和方法有一个宏观的认识，如果要系统地学习这些知识，可以阅读本书推荐的相关资料。
2.1 设计原则与软件设计
众所周知，设计原则是设计模式的基石。当遵循设计原则的时候，写出的代码就会变得非常灵活，并且可以应对变化，也更加容易维护。当然，也不是那么绝对。下面首先会简要介绍一些基本的设计原则，然后再介绍Robert C. Martin的S.O.L.I.D原则。
2.1.1 设计原则简述
KISS原则（Keep It Simple Stupid）
软件开发中常常遇到的问题就是：把一个问题过度的复杂化。KISS原则的目的就是提倡在设计和编码中，尽量保持代码的简约，避免不必要的复杂。简约不等于简单。
DRY原则（Don’t Repeat Yourself）
DRY原则的目的就是：抽取系统中的公共部分，并把它放置在一个地方以避免重复。这个原则不只是适用于代码中，而且也可以用于功能和业务逻辑上，确保不重复。这就要求对系统的职能有良好的分割，每个功能之间有着清晰的界限，用例之间不存在交叉。
Tell，Don’tAsk
这个原则是与封装有关的，要求对代码进行合理的封装，并把它们放到正确的类中。同时这个原则也指出：必须明确告诉对象：我们想要它们去执行什么样的操作，而不是首先询问对象的状态，然后我们自己决定去执行什么操作。
YAGNI原则（You Ain’tGonna Need It）
YAGNI原则指出：系统中只包含所必须的功能，不要包含你认为将来可能会用到的功能或者特性，防止过度设计。这个原则在TDD中体现得比较完全。在TDD中，首先写出代表系统必须功能的测试用例，然后再实现系统的功能代码，然后进行测试，直至测试代码通过。
SoC原则（Separation Of Concerns）
SoC就是把一个软件功能分离为单独功能点。被分离的每个功能点有唯一的行为和数据，而且每个功能点都能够被其他所需要的类单独使用。通过这个原则，我们可以最大限度地实现代码重用、功能重用、模块重用。
讲述了一些基本的设计原则之后，再来看看Bob在《敏捷软件开发设计》
[1]
一书中提到的五个原则，简称S.O.L.I.D原则。
S.O.L.I.D原则融合了基本的原则，并且提出了更加具有可操作性的方法。
SRP（Single Responsibility Principle ）
单一职责原则：就一个类而言，应该仅有一个引起它变化的原因。如果一个类承担的职责过多，就等于把这些职责都耦合在一起了。一个职责的变化可能会削弱或抑制这个类完成其他职责的能力。这个原则，不仅仅适用于类的设计上，还适用于接口以及模块的设计上。
OCP（Open-Closed Principle）
开放-封闭原则：软件实体（类，模块等）应该是可以扩展的，但是不可修改。只有在设计和开发中遵守OCP原则，才能避免在新加功能之后产生连锁反应。OCP关注的是灵活性：功能的改动是通过增加代码进行的，而不是修改现有的代码。一般来说，OCP是通过融合ISP（接口分离原则）和创建抽象来隔离后面同类型的变化的，LSP（里氏替换原则）使得这个目标成为可能。
LSP（Liskov Substitution Principle）
里氏替换原则：子类型必须能够替换掉它们的基类型。
ISP（Interface Segregation Principle）
接口分离原则：不应该强迫类实现它不需要的方法。如果一个接口中包含了很多不大而且不相关的方法，那么这个接口就必须要被分组，然后分离成多个接口，让实现接口的类只是去实现它所需要的方法。同时这也体现了在设计中，要尽量遵从SRP（单一职责原则）。
DIP（Dependency Inversion Principle）
依赖倒置原则：高层的模块不应该依赖于低层的模块，二者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象。高层模块是指系统不经常发生变化的部分，是一个系统区别于其他系统的重要标志，它包含了系统的策略选择与业务模型。低层模块是指系统中经常发生变化的部分。
上面讲了一些设计原则，下面就来举例说明一下，加深对这些原则的思考。
本文转自yanyangtian51CTO博客，原文链接：http://blog.51cto.com/yanyangtian/754128
，如需转载请自行联系原作者
