六大设计原则之“单一职责原则”

单一职责原则的定义是:应该有且仅有一个原因引起类的变更。

 

举例一:电话

 

传统设计:

一个接口类

1.IPhone:dial(),chat(),hangup()

一个实现类

1.Phone

 

演变思想:

因为dial和hangup实现的是协议管理,而chat实现的是数据传送;协议的接通和数据的传送都会引起这个接口类或实现类的变化;如拨号和挂断方法只管连接和断开,之后是不关心数据的传送;若按传统设计,一个类就包含了两个职责。

 

符合该原则的设计:

两个接口类

1.IConnectionManager:dial(),hangup()

2.IDataTransfer:DataTransfer(IConnectionManager cm )

一个实现类

1.Phone

 

演变问题:

问:为什么演变成两个接口类后,却只有一个实现类,而不是给每一个接口都去实现一下,再强耦合成一个Phone类呢?两个接口是满足了单一职责原则,但实现类仍然没满足,实现类仍然会因两个原因而引变化呀?

答:是的。但若分别有两个实现类,组合在一起后再形成Phone类才能使用,那么组合就是强耦合,增加了类的数据和复杂度,而且在面向接口编程中,对外公开的是接口,而不是实现类。

 

接口一定要做到单一职责,而实现类的设计尽量 做到只有一个原因引起变化。

 

举例二:用户

 

传统设计:

一个接口类

1.IUserInfo:setUserId(),getUserId(),setUserName(),getUserName(),changePassword(),addNewUser()

一个实现类

1.UserInfo

 

演变思想:

用户的属性(userId,userName等)没有和用户的行为分开,这是一个严重的错误,应该把属性抽取成一个BO(业务对像),行为抽取成一个Biz(业务逻辑)。

 

符合该原则的设计:

两个接口类

1.IUserBO:setUserId(),getUserId(),setUserName(),getUserName()

2.IUserBiz:changePassword(),addNewUser()

一个实现类

1.UserInfo

 

使用时如:

......

// 要赋值了就认为它是一个纯粹的BO

IUserBO userBO = (IUserBO) userInfo();

userBO.getUserId();

......

// 要执行动作了就认为它是一个逻辑类

IUserBiz userInfo = (IUserBiz) userInfo();

userInfo.addNewUser();

 

也适用对方法的设计

 

单一职责适用于接口、类,也同样适用于类里面的方法,即一个方法尽可能做一件事情。

比如修改用户信息,根据传递类型的不同,把可变长度的参数修改到userBO这个对像上,并写入数据库:

 

boolean changeUserInfo(IUserBO userBO, String... changeOptions);

 

这个方法的设计不符合该原则,因为方法的职责不清晰,不单一,不要让别人去猜测这个方法是用来处理什么逻辑的。

比如好的设计如:

 

boolean changeUserName(String newUserName);

boolean changeTel(String newTel);

 

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值