系统接口设计6大原则（软件接口设计原则）

本篇文章给大家谈谈系统接口设计6大原则，以及软件接口设计原则对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享系统接口设计6大原则的知识，其中也会对软件接口设计原则进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、设计模式六大原则(四)----接口隔离原则
• 2、六大设计原则之接口分离原则（Interface Segregation Principle）
• 3、系统接口设计的原则（续）
• 4、北大青鸟设计培训：软件开发涉及到的六个重要原则？
• 5、系统设计与分析都应该遵循哪些原则？
• 6、OA设计的六大原则是？

设计模式六大原则(四)----接口隔离原则

也就是说: 接口尽量细化，接口中的方法尽量少

从功能上来看，接口隔离原则和单一职责原则都是为了提高类的内聚, 降低类之间的耦合, 体现了封装的思想。但二者还是有区别的。

（1）从原则约束来看: 接口隔离原则更关注的是接口依赖程度的隔离；而单一职责原则更加注重的是接口职责的划分。

（2）从接口的细化程度来看: 单一职责原则对接口的划分更加精细，而接口隔离原则注重的是相同功能的接口的隔离。接口隔离里面的最小接口有时可以是多个单一职责的公共接口。

（3）单一职责原则更加偏向对业务的约束: 接口隔离原则更加偏向设计架构的约束。这个应该好理解，职责是根据业务功能来划分的，所以单一原则更加偏向业务；而接口隔离更多是为了“高内聚”，偏向架构的设计。

接口隔离原则是为了约束接口、降低类对接口的依赖性，遵循接口隔离原则有以下 5 个优点。

在具体应用接口隔离原则时，应该根据以下几个规则来衡量。
1）接口要尽量小
不能出现Fat Interface；但是要有限度，首先不能违反单一职责原则（不能一个接口对应半个职责）。

2）接口要高内聚
在接口中尽量少公布public方法。
接口是对外的承诺，承诺越少对系统的开发越有利。

3）定制服务
只提供访问者需要的方法。例如，为管理员提供IComplexSearcher接口，为公网提供ISimpleSearcher接口。

4）接口的设计是有限度的
了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同, 需要深入了解业务逻辑。

下面以学生成绩管理为例来说明接口隔离原则:

分析：学生成绩管理程序一般包含查询成绩、新增成绩、删除成绩、修改成绩、计算总分、计算平均分、打印成绩信息等功能，通常我们会怎么做呢？

通常我们设计接口的方式如下:

我们会吧所有的功能都放在一个接口里面. 这会产生什么样的问题呢?
首先, 接口的方法很多, 不利于扩展. 比如: 学生只有查看成绩,打印成绩单的权限, 没有增删改的权限; 老师拥有所有的权限.
查询成绩单:

操作成绩单

可以看出问题. 查询成绩单, 我们只会用到两个方法, 可是因为实现了接口, 不得不重写所有的方法.
如果这时候增加需求--发送给家长, 只有老师才有这个权限, 学生没有这个权限. 可是, 在接口中增加一个抽象方法以后, 所有的实现类都要重写这个方法. 这就违背了开闭原则.

采用接口隔离原则设计的接口, UML图如下:

我们将原来的一个接口进行了接口拆分. 分为查询接口和操作接口. 这样学生端就不需要重写和他不相关的接口了.

如果将这些功能全部放到一个接口中显然不太合理，正确的做法是将它们分别放在输入模块、统计模块和打印模块等 3 个模块中，其类图如图 1 所示

六大设计原则之接口分离原则（Interface Segregation Principle）

即：多个特定的客户端接口要好于一个通用性的总接口。

需要注意的是：接口的粒度也不能太小。如果过小，则会造成接口数量过多，使设计复杂化。

避免同一个接口里面包含不同类职责的方法，接口责任划分更加明确，符合高内聚低耦合的思想。

下面通过一个餐厅服务的例子讲解一下接口分离原则。

现在的餐厅除了提供传统的店内服务，多数也都支持网上下单，网上支付功能。写一些接口方法来涵盖餐厅的所有的下单及支付功能。

在这里声明了一个接口，它包含了下单和支付的几种方式：

对应的，我们有三种下单方式的顾客：

1.online下单，online支付的顾客

2.电话下单，online支付的顾客

3.在店里下单并支付的顾客：

我们发现，并不是所有顾客都必须要实现 RestaurantProtocol 里面的所有方法。 由于接口方法的设计造成了冗余，因此该设计不符合接口隔离原则 。

那么如何做才符合接口隔离原则呢？我们来看一下较好的设计。

要符合接口隔离原则，只需要将不同类型的接口分离出来即可。我们将原来的 RestaurantProtocol 接口拆分成两个接口：下单接口和支付接口。

下单接口：

支付接口：

现在有了下单接口和支付接口，我们就可以让不同的客户来以自己的方式实现下单和支付操作了：

首先创建一个所有客户的父类，来遵循这个两个接口：

接着另online下单，电话下单，店内下单的顾客继承这个父类，分别实现这两个接口的方法：

1.online下单，online支付的顾客

2.电话下单，online支付的顾客

3.在店里下单并支付顾客：

因为我们把不同职责的接口拆开，使得接口的责任更加清晰，简洁明了。不同的客户端可以根据自己的需求遵循所需要的接口来以自己的方式实现。

而且今后如果还有和下单或者支付相关的方法，也可以分别加入到各自的接口中，避免了接口的臃肿，同时也提高了程序的内聚性。

下面来看一下这两个设计的UML 类图，可以更形象地看出两种设计上的区别：

未实践接口分离原则：

实践了接口分离原则：

在设计接口时，尤其是在向现有的接口添加方法时，我们需要仔细斟酌这些方法是否是处理同一类任务的：如果是则可以放在一起；如果不是则需要做拆分。

做iOS开发的朋友对 UITableView 的 UITableViewDelegate 和 UITableViewDataSource 这两个协议应该会非常熟悉。这两个协议里的方法都是与 UITableView 相关的，但iOS SDK的设计者却把这些方法放在不同的两个协议中。原因就是这两个协议所包含的方法所处理的任务是不同的两种：

很显然， UITableView 协议的设计者很好地实践了接口分离的原则，值得我们大家学习。

系统接口设计的原则（续）

昨天写到系统接口设计最重要的原则是：

很开心的是大家选了黎叔和Richardson的方案，因为这个方案是最 简单直观 的，并且满足了数据在两个系统的一致性。

还是举昨天的例子，数据在客户系统是这样的：

到我们系统也会生成一样的数据：

我们系统为了生成这条数据，还需要生成一些基础数据：

这个方案的唯一问题是一个正常的SR(一装一卸)被分成了两个SR，一个是提货SR，一个是卸货SR，和我们之前对SR的认知十分不同，除了心里有些小担心之外，暂时也想不出这样会有什么问题。

抛开这个问题，我想用三个词来评价这个解决方案：

北大青鸟设计培训：软件开发涉及到的六个重要原则？

软件开发原则问题系统接口设计6大原则我们已经给大家在前几期的文章中多次强调系统接口设计6大原则了其重要性。
尤其是不能违反用户的常规使用习惯。
今天系统接口设计6大原则，IT培训http://www.kmbdqn.cn/就一起来了解一下，软件开发原则中的六个比较重要的原则都有哪些。
一、单一职责原则1、单一职责定义单一职责原则系统接口设计6大原则：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。
单一职责原则告诉我们：一个类不能太“累”!在软件系统中，一个类承担的职责越多，它被复用的可能性就越小，而且一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作，因此要将这些职责进行分离，将不同的职责封装在不同的类中，即将不同的变化原因封装在不同的类中，如果多个职责总是同时发生改变则可将它们封装在同一类中。
2、单一职责优点1)降低了类的复杂度。
一个类只负责一项职责比负责多项职责要简单得多。
2)提高了代码的可读性。
一个类简单了，可读性自然就提高了。
3)提高了系统的可维护性。
代码的可读性高了，并且修改一项职责对其他职责影响降低了，可维护性自然就提高了。
4)变更引起的风险变低了。
单一职责大的优点就是修改一个功能，对其他功能的影响显著降低。
二、里氏代换原则这个和单一职责原则比起来，显然就好理解多了，而且也不那么模糊不清。
1、定义官方定义：所有引用基类(父类)的地方必须能透明地使用其子类的对象。
简单理解就是：子类一般不该重写父类的方法，因为父类的方法一般都是对外公布的接口，是具有不可变性的，你不该将一些不该变化的东西给修改掉。
是不是感觉这个原则不太招人喜欢，因为我们在写代码的时候经常会去重写父类的方法来满足我们的需求。
而且在模板方法模式，缺省适配器，装饰器模式等一些设计模式都会采用重写父类的方法。
怎么说呢，里氏代换原则的主要目的主要是防止继承所带来的弊端。
继承的弊端：继承作为面向对象三大特性之一，在给程序设计带来巨大便利的同时，也带来了弊端。
继承会增加了对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。
三、接口隔离原则1、定义当一个接口太大时，我们需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。
为什么要这么做呢?其实很好理解，因为你实现一个接口就是实现它所有的方法，但其实你并不需要它的所有方法，那就会产生：一个类实现了一个接口，里面很多方法都是空着的，只有个别几个方法实现了。
这样做不仅会强制实现的人不得不实现本来不该实现的方法，严重的是会给使用者造成假象，即这个实现类拥有接口中所有的行为，结果调用方法时却没收获到想要的结果。

系统设计与分析都应该遵循哪些原则？

系统分析与设计的基本原则
一、统一性原则。按照国家税务总局的出口退税的法规政策，兼顾各地业务处理的特殊性，制定统一的出口退税业务规范。
二、适用性原则。系统提供灵活的设置，保证各地在不违反基本退税流程规范的前提下，适应其手段和操作方法的不同。另外，本系统应是一个不断提高完善的系统，系统要能够进行不断的发展，同时能最大限度地适应未来的业务发展的需要。
三、易用性原则。本系统使用人员范围广，使用人员的计算机水平层次不一，有的基层单位计算机使用水平较低，很多地方缺少计算机专业人员，系统应尽可能的操作简便，维护简单。
四、可靠性原则。由于操作失误出现的故障，重新使用时，系统应有自举功能，一时的设备故障，系统应可进行恢复，不破坏数据的一致性和完整性。
五、安全性原则。系统的用户根据业务的需要，具有不同的安全级别及操作权限，系统要充分发挥操作系统、数据库、应用软件三层安全保证措施，以保证数据的安全性。系统内部重要业务操作均留有痕迹。
六、健壮性原则。本系统接受大量的外部数据，系统应对错误的数据和结构不合理的数据进行识别，拒绝接受错误数据和结构不合理数据。
七、易二次开发、易维护性原则。采用封装技巧，建立稳定的底层工具，核心技术文档随系统发布等手段，使具有基本技术水平的系统维护人员可以在一定程度上对系统进行较复杂的维护及一般性扩充。

OA设计的六大原则是？

这六大原则是：
1、实用性原则
实用就是务实不务虚，就是注重解决实际问题，做精、做细核心功能，兼顾常用的辅助功能，实现快捷、方便地布署和使用，并节省投资，降低风险。有OA起来功能一堆，什么客户、人事、财务、资产、知识管理等等一网打尽，却做得粗糙之极，中看不中用。
2、易用性原则
这就要求软件的界面友好，结构清晰，流程合理，功能一目了然，菜单操作充分满足用户的视觉流程和使用习惯。易理解、易学习、易使用、易维护、易升级，实现“傻瓜相机”式的操作，将实施、培训成本和周期降到最低。易用性对软件的顺利实施和使用具有至关重要的意义，易用性的欠缺造成项目失败的案例已经屡见不鲜。
3、先进性原则
OA一个先进的工具，所以应采用先进的技术架构和设计方法，融合先进的管理思想，结构化程度高，灵活性、扩展性、兼容性、升级性好，速度快，符合技术发展趋势，适应用户成长需要。此处需要注意的是避免受“惟技术论”和“惟概念论”的误导，无论是技术还是概念都要以适合自己为准。
4、稳定性原则
OA入到企业中后，就会让人产生很大的依赖性。所以系统从底层数据库到功能层应经过严格测试，数据库稳定，功能顺畅，没有堵塞、丢失数据的现象，能在不同的硬件、网络、操作系统以及操作习惯中长期平稳运行，适合大规模用户使用，以保证日常办公的正常进行。
5、安全性原则
OA统往往保存有企业的核心资料，也会有个人用户的一些保密资料，这就要求系统能有效防止外部各种病毒攻击和恶意攻击，能够进行严格、细致的访问权限管理，内部数据具有多种备份方式。必要的情况下，允许用户进行各种辅助的数据加密、密码保护、身份认证等控制措施。
6、拓展性原则
大部分用户在使OA段时间后，会增加一些功能模块或者OA其他软件系统互联，这就要求软件具有很好的拓展性，能够提供开放和标准的接口，在不影响系统正常使用的情况下与第三方系统灵活对接，实现不同应用系统的互联互通，构建用户的综合性信息处理中心平台。
根据六大设计原则，我们发现，要为用户体现完美的系统性能，就必须以应用为核心，以实用、易用、好用三大主线为出发点，全面兼顾技术、应用与发展的和谐统一。
虽然这六大标准都很重要，但是“水至清则无鱼”，没有任何一OA完美的，能做到其中几项就已经够优秀了。而且，不同的客户需求、特点不同，关注点也不同，只要把关注点设到“优秀”档，把非关注点达到“合格”档，就不难找到适合自己的OA。 关于系统接口设计6大原则和软件接口设计原则的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 系统接口设计6大原则的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于软件接口设计原则、系统接口设计6大原则的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。