接口设计六大原则

一.单一职责原则

Single Responsibility Principle, 简称SRP。

定义:There should never be more than one reason for a class to change.

应该有且仅有一个原因引起类的变更。

职责的划分?单一的定义和级别?

应该根据实际业务情况而定。关注变化点。

实际使用时,类很难做到职责单一,但是接口的职责应该尽量单一。

二.里氏替换原则

Liskov Substitution Principle, 简称LSP。

定义:Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

(所有引用基类的地方必须能透明地使用其子类的对象)

里氏替换原则为良好的继承定义了一个规范:

1.子类必须完全实现父类的方法

2.子类可以有自己的个性(属性和方法)。

3.覆盖或实现父类的方法时输入参数可以被放大。

4.覆写或实现父类的方法时输出结果可以被缩小。

注:在类中调用其他类时务必要使用父类或接口,如果不能使用父类或接口,则说明类的设计已经违背了LSP原则。

三.依赖倒置原则

Dependence Inversion Principle, 简称DIP

定义:High level modules should not depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstractions.

翻译过来,包含三层含义:

1.高层模块不应该依赖低层模块,两者都应该依赖其抽象。

2.抽象不应该依赖细节。

3.细节应该依赖抽象。

精简的定义: 面向接口编程。

Test-Driven Development 测试驱动开发是依赖倒置原则的最好体现。

测试驱动开发要求先写测试类,测试通过才写实现类,这就要求你要先想接口定义。

依赖的三种写法:

1.构造函数传递依赖对象。

2.Setter方法传递依赖对象。

3.接口声明依赖对象。

最佳实践:
1.每个类尽量都有接口或抽象类,或者抽象类和接口两者都具备。
2.变量的表面类型尽量是接口或抽象类。
3.任何类都不应该从具体类派生。
4.尽量不要覆写基类的方法。
5.结合里氏替换原则使用。

四.接口隔离原则:
接口--这里指用interface关键字定义的接口。
定义:
1.Clients should not be forced to depend upon interfaces that they don‘t use.(客户端不应该依赖它不需要的接口)
2.The dependency of one class to anther one should depend on the smallest possible interface.(类间的依赖关系应该建立在最小的接口上)

概括:建立单一接口,不要建立臃肿庞大的接口。

通俗来讲:接口尽量细化,同时接口中的方法尽量少。

如何细化?细化到什么程序?

没有统一的标准,应根据业务合理细分,适合业务才是重点。

保证接口的纯结性:
1.接口要尽量小。
2.接口要高内聚。
3.定制服务。
4.接口的设计是有限度的。

最佳实践:
1.一个接口只服务于一个子模块或业务逻辑。
2.通过业务逻辑压缩接口中的public方法,接口时常去回顾,尽量让接口达到“满身筋骨肉”,而不是“肥嘟嘟”的一大堆方法。
3.已经被污染了的接口,尽量去修改,若变更的风险较大,则采用适配器模式进行转化处理。
4.了解环境,拒绝盲从。每个项目或产品都有特定的环境因素,不要盲从大师的设计,要根据业务逻辑进行最好的接口设计。

五.迪米特法则
Law of Demeter, LOD。又称最少知识原则(Least Knowledge Principle, LKP)。
通俗来讲:一个类应该对自己需要耦合或调用的类知道得最少,你(被耦合或调用的类)的内部是如何复杂都和我没有关系,那是你的事情,我就调用你提供的public方法,其他一概不关心。

低耦合要求:
1.只和朋友交流
朋友类:出现在成员变量、方法的输入输出参数中的类。方法体内部的类不属于朋友类。
2.朋友间也是有距离的
迪米特法则要求类“羞涩”一点,尽量不要对外公布太多的public方法和非静态的public变量,尽量内敛,多使用private、package-private、protected等访问权限。
3.是自己的就是自己的
如果一个方法放在本类中,既不增加类间关系,也对本类不产生负面影响,就放置在本类中。
4.谨慎使用Serializable

六.开闭原则
Software entities like classes, modules and functions should be open for extension but closed for modifications.(一个软件实体如类、模块和函数应该对扩展开放,对修改关闭)

软件实体包括以下几个部分:
1.项目和软件产品中按照一定的逻辑规则划分的模块。
2.抽象和类。
3.方法。

变化的三种类型:
1.逻辑变化
2.子模块变化
3.可见视图变化

时间: 2024-11-06 07:26:00

接口设计六大原则的相关文章

设计模式六大原则/接口设计六大原则 之 迪米特法则(转)

定义:一个对象应该对其他对象保持最少的了解.迪米特法则(Law of Demeter)又叫作最少知识原则(Least Knowledge Principle 简写LKP),就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话.英文简写为: LoD. 目的:迪米特法则的初衷在于降低类之间的耦合.由于每个类尽量减少对其他类的依赖,因此,很容易使得系统的功能模块功能独立,相互之间不存在(或很少有)依赖关系. 迪米特法则不希望类之间建立直接的联系.如果真的有需要建立联系,也希望能通过它的友元类来

设计模式六大原则/接口设计六大原则 之 单一职责原则(1)

Single Responsibility Principle, 简称SRP. 定义:There should never be more than one reason for a class to change. 应该有且仅有一个原因引起类的变更. 职责的划分?单一的定义和级别? 应该根据实际业务情况而定.关注变化点. 实际使用时,类很难做到职责单一,但是接口的职责应该尽量单一.

《设计模式之禅》笔记整理--面对对象设计六大原则

第一章.面对对象设计六大原则: (1).单一职责原则:应该有且只有一个原因引起类的变更. 为什么要用单一职责原则:(1).类的复杂性降低,实现什么职责都有清晰明确的定义. (2).可读性提高,复杂性降低,当然可读性提高了. (3).可维护性提高,可读性提高,当然更容易维护了. (4).变更引起的风险降低,一个接口修改,只对相应的实现类有影响. 职责划分的例子:电话过程可以划分为两个职责:(1).协议管理(2).数据传送 :RBAC模型,基于角色的访问控制 (2).里氏替换原则:目的:增强程序的健

php设计六大原则

1.单一职责 定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 优点: 1).可以降低类的复杂度,一个类只负责一项职责,逻辑简单: 2).提高类的可读性,提高系统的可维护性: 3).变更引起的风险降低,变更是必然的. 2.里氏代换原则 定义:所有引用基类的地方必须能透明地使用其子类的对象,也就是说子类可以扩展父类的功能,但不能改变父类原有的功能 . 3.依赖倒置原则 定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象:抽象不应该依赖细节:细节应该依赖抽象. 此处理解

设计六大原则总结

1.单一职责原则(SRP) 定义:就一个类而言,应该仅有一个引起它变化的原因 为什么需要单一职责呢?如果一个类承担的职责过多,就等于把这些职责耦合在一起了,一个职责的变化可能会引起其它职责的变化,当变化发生时,设计会遭到意想不到的变化. 我们看看下面简单的类图,UserDiscount类具有两个方法,一个是获取等级类型,一个是计算折扣价格. 有两个不同的类在使用UserDiscount,Order需要获取用户等级和计算价格:User只需要获取用户等级,但不需要计算价格,这个设计违反类SRP,如果

【Android】透明状态栏在App中的实现与接口设计

By Sodino 文章目录 1. 认识透明状态栏 2. 透明状态栏Api及特性 3. 设置透明状态栏 4. 处理消失的系统状态栏区域 5. fitsSystemWindows 6. Activity中的接口设计 7. Fragment中的接口设计 8. 白色Titlebar的处理 9. 小米 与 魅族 与 (莫名其妙的)华为 10. 腾讯优测UTest GitHub源码:TransparentStatusbar源码中分两个app TestBasic: 透明状态栏实现的示例,方便debug 白色

effective c++18-25条款“接口设计与声明”整理

一.让接口容易被正确使用,不易被误用 接口设计的原则是,方便日后和其他用户的使用,不要把问题留给接口使用者 (1)用常规的用法调用"特别"设计的接口.所以需要尽可能的把自己的设计往常规上靠:数据对象的行为要尽可能符合内建对象(比如int)的行为:接口的名字和意义要尽可能一致(比如STL中的容器基本都有一个叫做size的返回容器大小的接口)--这样做鼓励用户去正确的看待和使用你的接口. (2)忘了处理调用接口后的遗留问题.因此不要让用户去"记得"做一些事情. 如设计一

设计模式 之 设计的 六大原则(4) 接口隔离原则

接口隔离原则 定义:客户端不应该依赖它不需要的接口:一个类对另一个类的依赖应该建立在最小的接口上. 问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法. 解决方案:将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系.也就是采用接口隔离原则. 举例来说明接口隔离原则: (图1 未遵循接口隔离原则的设计) 这个图的意思是:类A依赖接口I中的方法1.方法2.方法3,类B是对类A依赖的实现

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

定义: 客户端不应该依赖它不需要的接口:类之间的依赖关系应建立在最小的接口之上.接口隔离原则英文全称为Interface Segregation Principle ,简称为ISP. 个人理解: 通俗的来说,接口不能臃肿庞大,而使根据具体需要尽量的细化.接口中的方法也要尽可能的少.接口是设计对外的一种契约,通过分散定义多个接口可以预防将来变更的扩散,使得真个系统变得更加稳定和更具有可维护性. 问题由来: 类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类C不是最小的接口,那么