单一职责原则是什么
应该有且仅有一个原因引起变更。通俗的将就是一个接口一个类一个方法干的事情不要杂合在一起。
因为技术经验和技术水平,往往我们写出的代码基本上很少遵循单一的职责原则,具体还是要根据项目。在没有接触到单一职责原则我基本上不会分一个业务对象的属性和行为,这其实很不利于日后的维护和扩展。
单一职责的好处(三高)
可读性高,可维护性高,可扩展性高
例子
没有遵循单一职责的例子
public interface IUserInfo { boolean setUserInfo(UserInfo userInfo); UserInfo getUserInfo(); boolean changePassword(String password); }
修改成单一职责,可以将接口拆分成两个接口
Bussiness Logic
public interface IUserInfoBiz { boolean changePassword(String password); }
Bussiness Object
public interface IUserInfoBO { boolean setUserInfo(UserInfo userInfo); UserInfo getUserInfo(); }
职责单一了,我们的类也变多了,其实还是需要根据项目实际出发。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。