1.1.4  局限性

设计模式并非银弹。您必须充分理解首要解决的问题，将其泛化，然后运用某个适合它的模式。但是，并非所有问题都需要设计模式。设计模式确实能够帮助人们将复杂的问题变得简单，但是同样也能够让本来简单的问题变得复杂。

在阅读有关模式的书籍之后，许多开发者都掉进了一个陷阱：试图把设计模式运用到所做的每件事情，但最终取得的效果却与设计模式初衷(也就是让事情变得简单)相反。前面曾经说过，运用模式的较好方法是，通过识别正在试图解决的基本问题，来寻找适合它的解决方案。本书将帮助您识别什么时候以及如何使用设计模式，继而从ASP.NET的角度来讨论如何实现。

并非总要使用设计模式。如果您已经为某个问题找到一种简单(但又不是过于简陋的)、清晰而且可维护的解决方案，那么倘若该方案并不属于GoF(四人组)设计模式中的某一个模式，也不要责备自己。否则，就会让自己的设计过于复杂。

这段有关设计模式的讨论此时给人的感觉可能相当模糊，但是在继续阅读本书的过程中，您将学习每个设计模式打算解决的问题类型，并了解如何在ASP.NET中实现这些设计模式，然后就能够将这些模式运用到自己的应用程序中。

1.2  设计原则

设计原则构成了设计模式赖以构建的基础。它们要比设计模式更加基础。通过遵循经过验证的设计原则，自己的代码基会变得更加灵活、更能够适应变化，而且可维护性更佳。下面将简要地介绍一些比较著名的设计原则以及一组被称为S.O.L.I.D.原则的原则。在本书后面将更为深入地了解这些原则，然后在ASP.NET中实现它们及最佳实践。

1.2.1  常见设计原则

如同设计模式一样，有一些常见的设计原则历经多年已经变成了最佳实践，并构成了企业级软件和可维护软件可以赖以构建的基础。下面将预览一些广为人知的原则。

1. 简约原则(KISS)

软件编程领域普遍存在的一个问题是需要把解决方案过度复杂化。KISS原则的目标就是让代码保持简洁但不要过于简陋，从而避免引入任何不必要的复杂度。

2. 不要重复自已(DRY)

DRY原则的目的是通过将公用的部分抽离出来放在一个单独的地方从而避免重复系统中的任何部分。这个原则不仅涉及代码而且包括系统中重复的任何逻辑。最终，系统中的任何一部分知识都应该只有一种表示形式。

3. 讲述而不要询问(Tell, Don't Ask)

“讲述而不要询问”原则体现了封装以及将责任指派到正确的类这两个思想。这个原则要求，应该告诉对象您希望它们执行什么动作，而不是询问有关该对象状态的问题然后由您自己决定希望执行什么动作。这个原则有助于匹配责任并避免类之间的紧密耦合。

4. 您不需要它(YAGNI)

YAGNI原则指的是只需要将应用程序必需的功能包含进来，而不要试图添加任何其他您认为可能需要的功能。测试驱动开发(TDD)就是一种坚持YAGNI原则的设计方法学。TDD的宗旨就是编写测试来验证系统的功能，然后只需要编写可让测试通过的代码即可。本章稍后部分将讨论TDD。

5. 分离关注点(SoC)

SoC这一过程将软件分解为多项不同的功能，每项功能封装了可供其他类使用的唯一行为和数据。通常，一个关注点代表类的一项功能或行为。将程序划分成若干独立职责的做法显著提高了代码的重用程度、维护性和可测试性。

在本书剩余部分将追溯这些设计原则，这样您就能够了解它们是如何实现的，以及如何帮助建立干净的、可维护的面向对象系统。下面将要看到的是S.O.L.I.D.设计原则分类中收集的设计原则。