《.NET应用架构设计：原则、模式与实践》新书博客-2.1.1-设计原则简述

第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）

 

依赖倒置原则：高层的模块不应该依赖于低层的模块，二者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象。高层模块是指系统不经常发生变化的部分，是一个系统区别于其他系统的重要标志，它包含了系统的策略选择与业务模型。低层模块是指系统中经常发生变化的部分。

上面讲了一些设计原则，下面就来举例说明一下，加深对这些原则的思考。

 

    当当网： http://product.dangdang.com/product.aspx?product_id=22574513

    京东地址： http://book.360buy.com/10893935.html

    卓越地址： http://www.amazon.cn/mn/dp/B006NS2N0S