本文目录一览：
- 1、软件开发涉及到的六个重要原则？
- 2、软件设计的原则是什么
- 3、软件设计原则有哪些
- 4、系统设计的原则
- 5、软件设计的原则有哪些
- 6、简述系统设计的原则
软件开发涉及到的六个重要原则？
软件开发原则问题我们已经给大家在前几期的文章中多次强调了其重要性。尤其是不能违反用户的常规使用习惯。今天，IT培训就一起来了解一下，软件开发原则中的六个比较重要的原则都有哪些。
一、单一职责原则
1、单一职责定义
单一职责原则：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。
单一职责原则告诉我们：一个类不能太“累”!在软件系统中，一个类承担的职责越多，它被复用的可能性就越小，而且一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其
他职责的运作，因此要将这些职责进行分离，将不同的职责封装在不同的类中，即将不同的变化原因封装在不同的类中，如果多个职责总是同时发生改变则可将它们封装在同一类中。
2、单一职责优点
1)降低了类的复杂度。一个类只负责一项职责比负责多项职责要简单得多。
2)提高了代码的可读性。一个类简单了，可读性自然就提高了。
3)提高了系统的可维护性。代码的可读性高了，并且修改一项职责对其他职责影响降低了，可维护性自然就提高了。
4)变更引起的风险变低了。单一职责大的优点就是修改一个功能，对其他功能的影响显著降低。
二、里氏代换原则
这个和单一职责原则比起来，显然就好理解多了，而且也不那么模糊不清。
1、定义
官方定义：所有引用基类(父类)的地方必须能透明地使用其子类的对象。
简单理解就是：子类一般不该重写父类的方法，因为父类的方法一般都是对外公布的接口，是具有不可变性的，你不该将一些不该变化的东西给修改掉。
是不是感觉这个原则不太招人喜欢，因为我们在写代码的时候经常会去重写父类的方法来满足我们的需求。而且在模板方法模式，缺省适配器，装饰器模式等一些设计模式都会采用重写父类的方法。
怎么说呢，里氏代换原则的主要目的主要是防止继承所带来的弊端。
继承的弊端：
继承作为面向对象三大特性之一，在给程序设计带来巨大便利的同时，也带来了弊端。
继承会增加了对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。
三、接口隔离原则
1、定义
当一个接口太大时，我们需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。
为什么要这么做呢?
其实很好理解，因为你实现一个接口就是实现它所有的方法，但其实你并不需要它的所有方法，那就会产生：一个类实现了一个接口，里面很多方法都是空着的，只有个别几个方法实现了。
这样做不仅会强制实现的人不得不实现本来不该实现的方法，严重的是会给使用者造成假象，即这个实现类拥有接口中所有的行为，结果调用方法时却没收获到想要的结果。
软件设计的原则是什么
软件设计是一个创造性的过程，对一些设计者来说需要一定的资质，而最后设计通常都是由一些初步设计演变而来的。从书本上学不会设计，只能经过实践，通过对实际系统的研究和实践才能学会。对于高效的软件工程，良好的设计是关键，一个设计得好的软件系统应该是可直接实现和易于维护、易懂和可靠的。设计得不好的系统，尽管可以工作，但很可能维护起来费用昂贵、测试困难和不可靠，因此，设计阶段是软件开发过程中最重要的阶段。
软件设计原则有哪些
七大设计原则
开闭原则
依赖导倒置原则
单一职责原则
接口隔离原则
迪米特原则
里氏替换原则
合成复用原则
设计模式-创建型模式
工厂方法模式
抽象工厂模式
建造者模式
单例模式
原型模式
设计模式-结构性模式
适配器模式
装饰者模式
代理模式
外观模式
桥接模式
组合模式
享元模式
设计模式-行为型模式
策略模式
模板方法模式
观察者模式
访问者模式
迭代器模式
责任链模式
中介者模式
解释器模式
状态模式
命令模式
备忘录模式
软件设计原则介绍
所以，可以说软件系统是连接需求分析、硬件系统以及使得系统实现的桥梁，对软件的设计应首先了解软件设计的设计原则。
设计原则
(1)可靠性
软件系统的规模越做越大越加复杂，其可靠性越来越难保证。应用本身对系统运行的可靠性要求越来越高，软件系统的可靠性也直接关系到设计自身的声誉和生存发展竞争能力。软件可靠性意味着该软件在测试运行过程中避免可能发生故障的能力，且一旦发生故障后，具有解脱和排除故障的能力。软件可靠性和硬件可靠性本质区别在于：后者为物理机理的衰变和老化所致，而前者是由于设计和实现的错误所致。故软件的可靠性必须在设计阶段就确定，在生产和测试阶段再考虑就困难了。
(2)健壮性
健壮性又称鲁棒性，是指软件对于规范要求以外的输入能够判断出这个输入不符合规范要求，并能有合理的处理方式。软件健壮性是一个比较模糊的概念，但是却是非常重要的软件外部量度标准。软件设计的健壮与否直接反应了分析设计和编码人员的水平。
(3)可修改性
要求以科学的方法设计软件，使之有良好的结构和完备的文档，系统性能易于调整。
(4)容易理解
软件的可理解性是其可靠性和可修改性的前提。它并不仅仅是文档清晰可读的问题，更要求软件本身具有简单明了的结构。这在很大程度上取决于设计者的洞察力和创造性，以及对设计对象掌握得透彻程度，当然它还依赖于设计工具和方法的适当运用。
(5)程序简便
(6)可测试性
可测试性就是设计一个适当的数据集合，用来测试所建立的系统，并保证系统得到全面的检验。
(7)效率性
软件的效率性一般用程序的执行时间和所占用的内存容量来度量。在达到原理要求功能指标的前提下，程序运行所需时间愈短和占用存储容量愈小，则效率愈高。
(8)标准化原则
在结构上实现开放，基于业界开放式标准，符合国家和信息产业部的规范。
(9)先进性
满足客户需求，系统性能可靠，易于维护。
(10)可扩展性
软件设计完要留有升级接口和升级空间。对扩展开放，对修改关闭。
（11）安全性
安全性要求系统能够保持用户信息、操作等多方面的安全要求，同时系统本身也要能够及时修复、处理各种安全漏洞，以提升安全性能。
系统设计的原则
系统总体设计应当根据系统工程的设计思想，使开发的系统满足科学化、合理化、经济化的总体要求。一般遵循以下基本原则。
( 1) 完备性
完备性主要是指系统的功能齐全、完备，能够满足用户的需要，系统要具备数据采集、管理、处理、查询、编辑、显示、分析及输出等功能。
( 2) 系统性
运用 GIS 软件开发的系统，空间数据和属性数据必须能够有机地结合为一体，各种参数可以互相进行传输。
( 3) 可靠性
系统的可靠性包括两个方面，一是系统运行的安全性，系统必须保证能够长期安全可靠稳定的运行; 二是运用 GIS 软件进行开发采集数据精度的可靠性和符号内容的完整性。
( 4) 实用性
系统数据组织灵活，可以满足不同应用分析的需求。系统真正做到能够解决用户所关心的问题，为生产实践、科研教学服务。
( 5) 可扩充性
考虑到计算机技术、用户方未来的发展，系统设计时应采用模块化结构设计，模块的独立性强，模块增加、减少或修改均对整个系统的影响很小，便于对系统进行改进、扩充，使系统处于不断完善的过程中，利于系统的扩充和完善。
( 6) 易操作性
计算机技术的特点及发展方向决定了它必须方便用户的使用，节省时间和费用，提高效率，只有这样才有其存在的价值和市场。系统用户文化程度参差不齐，低学历所占比例较大，因此系统必须具有友好的用户界面便于用户操作，易于用户学习掌握 ( 毛善君等，2003) 。
软件设计的原则有哪些
(1)可靠性
用软件系统规模越做越大越复杂，其可靠性越来越难保证。应用本身对系统运行的可靠性要求越来越高，软件系统的可靠性也直接关系到设计自身的声誉和生存发展竞争能力。软件可靠性意味着该软件在测试运行过程中避免可能发生故障的能力，且一旦发生故障后，具有解脱和排除故障的能力。软件可靠性和硬件可靠性本质区别在于：后者为物理机理的衰变和老化所致，而前者是由于设计和实现的错误所致。故软件的可靠性必须在设计阶段就确定，在生产和测试阶段再考虑就困难了。
(2)健壮性
健壮性又称鲁棒性，是指软件对于规范要求以外的输入能够判断出这个输入不符合规范要求，并能有合理的处理方式。软件健壮性是一个比较模糊的概念，但是却是非常重要的软件外部量度标准。软件设计的健壮与否直接反应了分析设计和编码人员的水平。
(3)可修改性
要求以科学的方法设计软件，使之有良好的结构和完备的文档，系统性能易于调整。
(4)容易理解
软件的可理解性是其可靠性和可修改性的前提。它并不仅仅是文档清晰可读的问题，更要求软件本身具有简单明了的结构。这在很大程度上取决于设计者的洞察力和创造性，以及对设计对象掌握得透彻程度，当然它还依赖于设计工具和方法的适当运用。
(5)程序简便
(6)可测试性
可测试性就是设计一个适当的数据集合，用来测试所建立的系统，并保证系统得到全面的检验。
(7)效率性
软件的效率性一般用程序的执行时间和所占用的内存容量来度量。在达到原理要求功能指标的前提下，程序运行所需时间愈短和占用存储容量愈小，则效率愈高。
（8）标准化原则
在结构上实现开放，基于业界开放式标准，符合国家和信息产业部的规范。
（9）先进性
满足客户需求，系统性能可靠，易于维护。
（10）可扩展性
软件设计完要留有升级接口和升级空间。
简述系统设计的原则
系统设计的一些原则
在进行系统设计时，不仅要考虑软件的功能性需求，还要考虑非功能性需求，比如软件的性能(Performance)、可扩展性(Scalability)，系统的稳定性(Reliability)、部署(Deployment)和更新(Upgrade)，可维护性(Maintainability)，版本的管理，系统的安全(Security)，界面的友好程度可用性(Usability, User experience)等。要想覆盖所有需求，实现一个简单而优秀的系统，可谓艰难。
大道至简，合适最好
什么是优秀的系统设计？ 这个问题颇有争议，但几乎每个软件工程师和架构师都追求优秀的系统设计。当然，系统设计并不代表结果，系统设计只是架构师或者带头程序员的工作，优秀的系统设计必须经由良好的项目管理和团队努力，经过分析需求、设计、开发、测试、分发、维护，以及迭代或重构的过程。中间哪个环节出了问题，再好的设计都将功亏一篑。
可能每个人都对自己设计的系统很自信很满意，但“实践是检验真理的唯一标准”。如果一个系统设计经过实践证明，大家(指客户或用户)公认为优秀的系统，那就是一个优秀的系统设计。
大道至简，适合的就是最好的。其实设计并没有那么严重，适合的就是最好的，简单最好。软件也是一种服务，这个系统设计出来就是为了服务一些用户还没有被满足的需求，如果你能够恰好满足了这些没有被满足的需求，而且能以比较低的代价提供这种服务，那这就是最好的系统。因为系统设计的来源是商业需求，而商业追求利益最大化。你的软件和服务必须比别人功能更加先进，更加好用，对变化的商业 需求反应更加灵活，推出或者升级的速度更快，开发和维护成本更低，才能证明这个系统设计的优秀性。所以系统简单，不能说明你的系统不优秀，说不定设计者有化繁为简的过人能力；系统复杂，功能繁多，也不能说明系统优秀。
技术人员常常犯的错误是技术至上，技术第一，不计成本的去设计和开发无比先进和灵活的系统，不计风险的去采用最新的没经过实用的新技术。所以作为架构师，不仅仅需要精通技术，更需要良好的沟通协调，去了解业务和客户真正的需求，真正站在客户利益角度和最终用户利益角度思考问题和设计系统，在各种选择中做出权衡。
极限编程人士的一个响亮的口号是“You aren't going to need it”。这其中包含的核心意义就是不要为了考虑程序的可扩展性，把目前不需要的功能加入到软件中来。不要过度设计。抓住重点，合适就好。比如根据二八原则，80%的用户只会使用20%的功能，而这20%的功能就是客户最关注的最需要的功能，也就是软件或服务的“卖点“，系统设计时必须集中精力和充分考虑到这部分需求。如果把精力放在某些花哨的功能上，既不 重要，也没必要，那就是过度设计。要想避免过度设计，我觉得可以遵循敏捷开发方式来做。尽可能的简单设计，当满足不了时，重构；保证产品是可运行的，不断的加入新的特征；产品经常性的提交给客户使用。
发布于 2022-10-24 01:45:29 回复
发布于 2022-10-24 09:52:12 回复