面向对象基本原则（一）——单一职责原则和接口隔离原则面向对象基本原则（一）——单一职责原则和接口隔离principle面向对象基本原则（二）——李式替换原则和依赖倒置原则面向对象基本原则（三）——最少已知原则和开闭原则一、单一职责原则1、单一职责原则简介TheEnglish单一职责原则的名称是SingleResponsibilityPrinciple，简称SRP。单一职责原则的原始解释是：一个类改变的原因不应该超过一个。这意味着：应该有一个而且只有一个原因导致班级变更。2.单一职责原则降低了优势类的复杂度，实现什么职责都有清晰明确的定义。可读性增加，复杂性降低，当然可读性也会提高。可维护性提高了，可读性提高了，当然更容易维护了。变更带来的风险降低，变更必不可少。如果接口的单一职责做得好，一个接口修改只会影响对应的实现类，对其他接口没有影响，会影响系统的扩展性和可维护性。一切都非常有帮助。3.最佳实践接口必须单一职责，类的设计应该设计成只有一个变化的原因。注意，单一职责原则提出了编写程序的标准，用“职责”或“变更原因”来衡量接口或类是否设计良好，但“职责”和“变更原因”是不可衡量的，因人而异项目到项目，因环境而异。4.代码展示使用PHP7.2语法编写用户业务场景IUserBo接口负责用户属性接口IUserBo{publicfunctionsetUserID(string$userID);公共函数getUserID()：字符串；公共函数setPassword（字符串$密码）；公共函数getPassword()：字符串；公共函数setUserName(string$userName);publicfunctiongetUserName():string;}IUserBiz接口负责用户行为接口IUserBiz{publicfunctionchangePassword(string$password):bool;publicfunctiondeleteUser(IUserBo$userBo):bool;公共函数mapUser(IUserBo$userBo);公共功能addOrg(IUserBo$userBo,int$orgID):bool;/***给用户添加角色*@paramIUserBo$userBo*@paramint$roleID*@returnbool*/publicfunctionaddRole(IUserBo$userBo,int$roleID):bool;}UserInfo类实现了IUserBo、IUserBiz两个接口类UserInfo实现IUserBo，IUserBiz{publicfunctionsetUserID(string$userID){//TODO：实现setUserID()方法。}publicfunctiongetUserID():string{//TODO:实现getUserID()方法。}publicfunctionsetPassword(string$password){//TODO：实施setPassword()方法。}publicfunctiongetPassword():string{//TODO:实现getPassword()方法。}publicfunctionsetUserName(string$userName){//TODO：实施setUserName()方法。}publicfunctiongetUserName():string{//TODO:实现getUserName()方法。}publicfunctionchangePassword(string$password):bool{//TODO:实现changePassword()方法。}publicfunctiondeleteUser(IUserBo$userBo):bool{//TODO:实现deleteUser()方法。}publicfunctionmapUser(IUserBo$userBo){//TODO：实现mapUser()方法。}publicfunctionaddOrg(IUserBo$userBo,int$orgID):bool{//TODO:实现addOrg()方法。}公共赋nctionaddRole(IUserBo$userBo,int$roleID):bool{//TODO:实现addRole()方法。}}$userInfo=newUserInfo();//赋值，它被认为是一个纯属性$userInfo->setPassword("abc");//执行一个动作，它被认为是一个业务逻辑类$userInfo->deleteUser($用户信息);二、接口隔离原则1、接口隔离原则简介接口隔离原则的英文名称是InterfaceSegregationPrinciple，简称ISP接口隔离原则，有两个英文定义：Clientshouldnotbeforedtodependoninterfacesthattheydon使用。不应强迫客户依赖于他们不使用的接口。一个类对另一个类的依赖应该依赖于尽可能小的接口。类之间的依赖应该建立在尽可能小的接口上。我们可以将这两个定义概括为一句话：构建单一界面，不要构建臃肿庞大的界面。说得简单一点：接口越详细越好，接口中的方法越少越好。接口隔离原则和单一职责的区别接口隔离原则和单一职责有不同的观点。单一职责要求类和接口的职责单一，强调的是职责，就是业务逻辑的划分，而接口隔离原则要求接口上的方法越少越好。例如，一个接口的职责可能包括10个方法。这10个方法放在一个接口中，提供给多个模块访问。每个模块按照指定的权限访问。在系统之外，“未使用的方法”受文档约束。Donotaccess”，根据单一职责原则是允许的，根据接口隔离原则是不允许的，因为它要求“尽可能多地使用专用接口”。专用接口是指每个模块应该提供一个单一的接口，而不是创建一个庞大而臃肿的接口来容纳所有的客户端访问。2.接口隔离原则的规范接口应该尽可能小。这是接口隔离原则的核心定义，并且不会出现胖接口（FatInterface）。但“小”是有极限的。按照接口隔离原则拆分接口时，首先要满足单一职责原则。接口应该有高内聚高内聚就是提高接口、类、模块的处理能力，减少外部交互。具体到接口隔离原则，要求接口中尽量少使用公共方法。接口是一个外部承诺。承诺越少，系统开发越好，变更风险越小，也有利于降低成本。接口只提供访问者需要的方法，这是不争的事实。界面设计要适度。界面设计粒度越小，系统越灵活。但是，灵活性也带来了结构复杂、开发难度增加、可维护性降低等问题。这不是一个项目或产品希望看到的，所以界面设计一定要注意适度。3.最佳实践接口隔离原则是接口的定义，也是类的定义。接口和类应尽可能使用原子接口或原子类进行组装。关于如何划分原子，在实践中，可以按照以下规则来衡量：一个接口只服务于一个子模块或业务逻辑；接口中的public方法被业务逻辑压缩，经常review接口，尽量让接口达到“浑身是筋骨”，而不是一大堆“肥嘟嘟”的方法；被污染的接口应该尽量修改，如果修改风险大，应该使用适配器模式进行转换；每个项目或产品都有特定的环境因素，不同环境下接口拆分的标准也不一样。要有深刻的理解业务逻辑，根据经验和常识确定接口的粒度，接口粒度太小，导致接口数据激增，开发人员被接口的海洋噎死；接口粒度过大，灵活性降低，无法提供定制化服务，给整体项目带来不可预知的风险。参考：《设计模式之禅》
