乐趣区

关于设计模式:设计模式之禅01单一职责原则

繁多职责准则

1.1 我是“牛”类,我能够负责多职吗

繁多职责准则,英文名称是 Single Responsibility Principle,简称是 SRP,定义是应该有且仅有一个起因引起类的变更。

什么是类的职责,以及怎么划分类的职责?

举例:rbac 模型

这个接口设计的存在问题:用户属性和用户行为没有离开

把用户信息抽取成一个 BO(Business Object,业务对象),把行为抽取成一个 Biz(Business Logic,业务逻辑),咱们面向接口编程,所以产生的 UserInfo 对象能够当成 IUserBO 接口应用,也能够录成 IUserBiz 接口应用

IUserInfo userInfo = new UserInfo();
IUserBO userBO = (IUserBO)userInfo;
userBO.setPassword("abc");
IUserBiz userBiz = (IUserBiz)userInfo;
userBiz.deleteUser();

在理论应用中,咱们更偏向于应用两个不同的类或接口,如下:

1.2 绝杀技,突破你的传统思维

举例:电话设计

这么设计的问题是 IPhone 接口不只有一个职责,别离为:一个是协定治理,一个是数据传送。

这样设计引起类间耦合过重、类的数量减少,人为地减少了设计的复杂性

这样设计,一个类实现两个接口,把两个职责交融在一个类中。

繁多职责准则的益处

实现什么职责都有清晰明确的定义,这样类的复杂性升高,可读性进步,可维护性进步

1.3 我单纯,所以我高兴

繁多职责实用于接口、类,同时也实用于办法。

要批改用户名称,就调用 changeUserName 办法;要批改家庭地址,就调用 changeHomeAddress 办法;要批改单位电话,就调用 changeOfficeTel 办法。每个办法的职责十分清晰明确,不仅开发简略,而且日后的保护也非常容易。

1.4 最佳实际

大部分状况下类设计都是与繁多职责相违反的,类的繁多职责受到十分多因素的制约,事实你必须去思考我的项目工期、老本、人员技术水平、硬件状况、网络状况甚至有时候还要思考政府政策、垄断协定等因素。

对于繁多职责准则,倡议是接口肯定要做到繁多职责,类的设计尽量做到只有一个起因引起变动。

参考:

  1. 《设计模式之禅》第 2 版
退出移动版