软件设计基本原则

基本原则：

1、KISS原则

KISS：Keep it simple and stupid.（保持简单和直接原则）

任何事情都应该尽可能简单，而不是稍微简单一点。

                                                                          —— Albert Einstein，theoretical physicist

对于程序员来说，关注简单性可能是最困难的事情之一，并且这是一个终生的学习经验。

                                                                                              —— Adrian Bolboaca

2、YAGNI原则

YAGNI：You Aren't Gonna Need It!（不需要原则）

YAGNI原则向投机取巧和过度设计宣战，它的主旨是希望你不要写目前用不上，但将来也许会需要的代码。

总是在你需要的时候再实现它们，而不是在你只是预见到你需要它们的时候实现它们。

                                                                                               —— Ron Jeffries

建议：在你确定真的有必要的时候再写代码，那时再重构仍然来得及。

3、DRY原则

DRY：Don't repeat yourself!（避免复制原则）

复制和粘贴是一个设计错误。

                                         —— David L.parnas

复制是非常危险的，其原因显而易见：当一段代码被修改的时候，也必须相应地修改这段代码的副本，不要抱着不修改副本的期望，可以肯定的是，一定要修改副本。任何复制的代码片段迟早会被忘记，并且会因为漏改代码的副本而产生bug。

在一个系统内部，任何一个知识点都必须有一个单一的，明确、权威的陈述。

DRY原则同样适用于文档、项目、测试计划和系统的配置数据。

4、信息隐藏原则

该原则指出：一段代码调用了另外一段代码，那么调用者不应该知道被调用者的内部实现，否则调用者就有可能通过修改被调用者的内部实现而完成某个功能，而不是强制性地要求调用者修改自己的代码。

优点：

（1）限制了模块的变更范围。

（2）如果需求修复缺陷，对其他模块的影响最小。

（3）显著提高了模块的可复用性。

（4）模块具有更好的可测试性。

信息隐藏和封装：

信息隐藏是帮助开发人员找到好的设计模块的原则，该原则适用于多个抽象层次并能展现其正面效果，特别是在大型系统中。

封装通常依赖于编程语言的技术，用于限制对模块内部的访问。例如C++中private关键字定义的成员或者接口，以确保类外部无法访问，但仅用这种防护方式进行访问控制，离自动隐藏信息仍相差较远，封装有助于但不能保证信息隐藏。

5、高内聚原则

软件开发中的一条通用建议是：任何软件实体（如模块、组件、单元、类、函数等）应该具有很高（很强）的内聚性。一般来讲，当模块实现定义确切的功能时，应该具有高内聚的特性。

示例1：

 在上面的例子中，模块随意划分，业务领域三个不同的功能放在了一个模式内。功能A、功能B和功能C之间基本没有什么共同点，但是这三个功能却被放在MyModule模块中。阅读模块的代码就会发现，功能A、功能B和功能C在不同的、完全独立的数据上运行。

上图中箭头指向的每一个模块都是一个被依赖者，箭头尾部的模块需要箭头指向的模块来实现。在这种情况下，系统中的其他模块想要使用功能A、功能B和功能C时，调用的模块就会依赖于整个Mymodule模块。这样的设计缺点是显而易见的：这会导致太多的依赖，并且可维护性也会降低。

 示例2：

 现在，很容易看出，每个模块的依赖项要比旧的MyModule的依赖项少得多。模块A、模块B和模块C时间没有直接的关系。Module1是唯一依赖模块A、模块B和模块C的模块。

 示例3：（散弹枪模式）

 在这种低内聚方式下，出现了许多不利的依赖关系，功能A的各个片段必须紧密结合在一起。这就意味着，实现功能A子集的每一个模块必须至少与一个包含功能A子集的模块交互。这会导致大量的依赖性交叉。最坏的情况是导致循环依赖；比如，模块1和模块3之间，或者模块6和模块7之间。这再一次对可维护性和可扩展性产生了负面影响。这种设计的可测试性也非常差。

这种设计将导致所谓的“散弹枪手术”。对功能A的某种修改会导致很多模块进行或多或少的修改，这真的很糟糕，并且应该避免。我们应该把与功能A相关的所有代码都拿出来，把相同逻辑的代码放到一个高内聚的模块内。

6、松耦合原则

软件开发的过程中，应该寻求模块间的松耦合（也称为低耦合或弱耦合）。这意味着你应该构建一个系统，在该系统中，每个模块都应该很少使用或不知道其他独立模块的定义。

软件开发中，松耦合的关键是接口。接口声明类的公共行为，而不涉及该类的具体实现。接口就像合同，而实现接口的类负责履行契约，也就是说，这些实现接口的类必须为接口的方法签名提供具体的实现。

示例：

 上述示例中，灯和开关是紧耦合的。

通过接口Switchable接口，实现了Switch和Lamp的松耦合。

松耦合可以为系统的各个独立的模块提供高度的自治性，该原理可以适用于很多不同的层次：可以用在最小的模块上，当然，还可以用在大型组件的体系结构上。高内聚会促进松耦合，因为具有明确定义责任的模块，通常会依赖较少的其他模块。

7、小心优化原则

不成熟的优化是编程中所有问题（或者至少是大部分问题）的根源。

                                                                                  —— Donald E. Knuth

优化建议：只要没有明确的性能要求，就避免优化。

8、最少惊讶原则（PLA）

最少惊讶原则（PLA/POLA），也称为最少惊喜原则（POLS），它在用户界面设计和人因工程学设计中很知名。该原则指出不应该让用户对用户界面的意外响应而感到惊讶，也不应该对出现或消失的控件、混乱的错误消息、公认的按键序列的异常响应（记住，Ctrl+C是在Windows操作系统中复制应用程序的标准事物，而不是退出程序）或其他意外行为而感到困惑。

这个原则也可以很好地应用软件开发的API设计中。调用函数不应该让调用者感知到异常行为或一些隐藏的副作用，函数应该完全按照函数名称所暗示的意义执行。

9、童子军原则

原则：在离开露营地的时候，应该让露营地比你来之前还要干净。

每当我们在一段代码中发现需要改进的或者风格不好的代码时，我们应该立即修正它，与这段代码的原创作者是谁无关紧要。

这种行为的好处是我们能不断防止自己的代码被破坏。如果我们都那样做，diamante就不会变糟，软件熵增加的趋势也就没有机会能占据我们系统的主导地位。改善代码并不一定要大刀阔斧地去做，也可能只是一次小小的清理。

举例如下：

（1）重命名那些命名不佳的类、变量、函数或方法；

（2）将大型函数分解为更小函数；

（3）让需要注释的代码不言自明，以避免注释；

（4）清理复杂而令人费解的if-else组合；

（5）删除一小部分重复的代码（DRY原则）；

由于这些改进大多数都是代码重构，由良好的单元测试组成的坚固的安全体系是必不可少的。没有单元测试，根本无法确定你是否破坏了某些东西。