软件设计原则有哪些

七大设计原则

开闭原则

依赖导倒置原则

单一职责原则

接口隔离原则

迪米特原则

里氏替换原则

合成复用原则

设计模式-创建型模式

工厂方法模式

抽象工厂模式

建造者模式

单例模式

原型模式

设计模式-结构性模式

适配器模式

装饰者模式

代理模式

外观模式

桥接模式

组合模式

享元模式

设计模式-行为型模式

策略模式

模板方法模式

观察者模式

访问者模式

迭代器模式

责任链模式

中介者模式

解释器模式

状态模式

命令模式

备忘录模式

软件设计原则介绍

所以，可以说软件系统是连接需求分析、硬件系统以及使得系统实现的桥梁，对软件的设计应首先了解软件设计的设计原则。

设计原则

(1)可靠性

软件系统的规模越做越大越加复杂，其可靠性越来越难保证。应用本身对系统运行的可靠性要求越来越高，软件系统的可靠性也直接关系到设计自身的声誉和生存发展竞争能力。软件可靠性意味着该软件在测试运行过程中避免可能发生故障的能力，且一旦发生故障后，具有解脱和排除故障的能力。软件可靠性和硬件可靠性本质区别在于：后者为物理机理的衰变和老化所致，而前者是由于设计和实现的错误所致。故软件的可靠性必须在设计阶段就确定，在生产和测试阶段再考虑就困难了。

(2)健壮性

健壮性又称鲁棒性，是指软件对于规范要求以外的输入能够判断出这个输入不符合规范要求，并能有合理的处理方式。软件健壮性是一个比较模糊的概念，但是却是非常重要的软件外部量度标准。软件设计的健壮与否直接反应了分析设计和编码人员的水平。

(3)可修改性

要求以科学的方法设计软件，使之有良好的结构和完备的文档，系统性能易于调整。

(4)容易理解

软件的可理解性是其可靠性和可修改性的前提。它并不仅仅是文档清晰可读的问题，更要求软件本身具有简单明了的结构。这在很大程度上取决于设计者的洞察力和创造性，以及对设计对象掌握得透彻程度，当然它还依赖于设计工具和方法的适当运用。

(5)程序简便

(6)可测试性

可测试性就是设计一个适当的数据集合，用来测试所建立的系统，并保证系统得到全面的检验。

(7)效率性

软件的效率性一般用程序的执行时间和所占用的内存容量来度量。在达到原理要求功能指标的前提下，程序运行所需时间愈短和占用存储容量愈小，则效率愈高。

(8)标准化原则

在结构上实现开放，基于业界开放式标准，符合国家和信息产业部的规范。

(9)先进性

满足客户需求，系统性能可靠，易于维护。

(10)可扩展性

软件设计完要留有升级接口和升级空间。对扩展开放，对修改关闭。

（11）安全性

安全性要求系统能够保持用户信息、 *** 作等多方面的安全要求，同时系统本身也要能够及时修复、处理各种安全漏洞，以提升安全性能。

(1)可靠性

用软件系统规模越做越大越复杂，其可靠性越来越难保证。应用本身对系统运行的可靠性要求越来越高，软件系统的可靠性也直接关系到设计自身的声誉和生存发展竞争能力。软件可靠性意味着该软件在测试运行过程中避免可能发生故障的能力，且一旦发生故障后，具有解脱和排除故障的能力。软件可靠性和硬件可靠性本质区别在于：后者为物理机理的衰变和老化所致，而前者是由于设计和实现的错误所致。故软件的可靠性必须在设计阶段就确定，在生产和测试阶段再考虑就困难了。

(2)健壮性

健壮性又称鲁棒性，是指软件对于规范要求以外的输入能够判断出这个输入不符合规范要求，并能有合理的处理方式。软件健壮性是一个比较模糊的概念，但是却是非常重要的软件外部量度标准。软件设计的健壮与否直接反应了分析设计和编码人员的水平。

(3)可修改性

要求以科学的方法设计软件，使之有良好的结构和完备的文档，系统性能易于调整。

(4)容易理解

软件的可理解性是其可靠性和可修改性的前提。它并不仅仅是文档清晰可读的问题，更要求软件本身具有简单明了的结构。这在很大程度上取决于设计者的洞察力和创造性，以及对设计对象掌握得透彻程度，当然它还依赖于设计工具和方法的适当运用。

(5)程序简便

(6)可测试性

可测试性就是设计一个适当的数据集合，用来测试所建立的系统，并保证系统得到全面的检验。

(7)效率性

软件的效率性一般用程序的执行时间和所占用的内存容量来度量。在达到原理要求功能指标的前提下，程序运行所需时间愈短和占用存储容量愈小，则效率愈高。

（8）标准化原则

在结构上实现开放，基于业界开放式标准，符合国家和信息产业部的规范。

（9）先进性

满足客户需求，系统性能可靠，易于维护。

（10）可扩展性

软件设计完要留有升级接口和升级空间。

1、量两次，切一次(Measure twice and cut once)

如果你只能从这篇文章中学到一个原则且最重要的一个，那么就是这个。 开发人员，架构师和经理人经常因为个人情绪、以及其他问题而难以集中注意力。

就工程师来说，这个原则意味着选择正确的解决方案，选择正确的方法来解决问题，选择正确的工具来解决问题，对建立的解决方案必须充满信心。

选择这里意味着投入一些思考，找到必要的资源，组建合适的团队，思考设计，思考方法，设定任务，控制结果，并为此承担责任。 这就是“活在当下”。 我认为我自己还没有准备好用正确的词汇来描述它。

2、不要重复自己(Don't Repeat Yourself)

这是一个相当简单但非常有用的原则，它说在不同的地方重复同样的事情是非常糟糕的。 首先，它涉及到进一步支持和修改代码的必要性。 如果某个代码片段在程序中的几个地方被复制，那么很有可能出现两种灾难性的情况:

当对源代码进行哪怕是很小的改动时，您需要在几个地方更改相同的代码。 这需要额外的时间、精力和注意力，而这件事件通常也非常不容易。

第一项紧随第二项。 团队中的其他开发人员可能会意外地错过其中一个更改(只合并了控制系统中的分支) ，并将面对应用程序中随后出现的一系列错误。 这些 bug 可能会让您感到沮丧，因为您已经听说这样的 bug 似乎已经被修复了。

在这方面，有一个建议ーー如果在清单中发现任何代码超过两次，则应以单独的方式来处置。 这是通用做法。 事实上，即使再次遇到重复的bug，您也应该考虑创建一个单独的方法。

3、奥卡姆剃刀(Occam’s Razor)

这是一个非常普遍的想法，它来自于哲学编程。 这个原则得名于奥克姆的英国修道士威廉。 这一原则表明: ”没有必要，不得增加实体”。

在工程学中，这一原则被解释为: 没有必要创建不必要的实体。 因此，首先考虑添加另一个方法 / 类 / 工具 / 流程等的好处不见得总是一个好主意。 毕竟，如果您添加了另一个方法 / 类 / 工具 / 流程等等，除了增加复杂性之外，您没有得到任何其他好处，那还有什么意义呢？

4、保持足够简单(Keep It Simple Stupid )

这是一个与上面非常类似的原则，但它的含义略有不同。 这个原则要求代码必须尽可能简单，不能有复杂的结构，否则会使代码的调试和维护复杂化。

此外，对于另一个程序员来说，理解代码的逻辑将会更加困难，这反过来也将需要额外的时间和精力。 这就是为什么您应该始终尝试使用简单的构造来尽可能多地解决问题，而不需要使用大量的分支、深层嵌套和过度重载的类结构。

通过这样做，你将使自己和同事的生活更加轻松，因为复杂性会产生错误。 记住 Peter Hintiens 说过的话: “简单永远比功能好”。

5、你不会需要它（You Aren’t Gonna Need It ）

这是许多程序员都会遇到的问题。 从项目一开始就希望立即实现所有必要的(有时甚至是不必要的)功能。 也就是说，当开发人员从一开始就将所有可能的方法添加到类中并实现它们时，甚至可能在未来永远不会使用它们。

因此，根据这个建议，首先，只实现您需要的东西，然后，如果必要的话，再扩展相应功能。 这样，您就可以节省调试代码的工作量、时间以及精力，而实际上这些代码却并不需要。

---