共京部電大学 1032开闭原则OCP(Open Closed Principle) ◆软件实体(类、模块、函数等应该是可以扩展、 但是不可修改的。 当需求改变时,可以对模块进行扩展,以满足需求的 变化。 对模块行为进行扩展时,不必改动客户端模块的源代 码或者二进制代码。 符合OCP原则的程序只通过增加代码来变化,而 不是通过更改现有代码来变化。 ◆实现OCP的关键是使用抽象来识别不同类之间的 共性和变化点,利用封装技术对变化点进行封装 ⊙2008 BUPT TSEG 北京邮电大学通信软件工程中心 16
© 2008 BUPT TSEG 北京邮电大学 通信软件工程中心 16 10.3.2开闭原则OCP(Open Closed Principle) ◆ 软件实体(类、模块、函数等)应该是可以扩展、 但是不可修改的。 ➢ 当需求改变时，可以对模块进行扩展，以满足需求的 变化。 ➢ 对模块行为进行扩展时，不必改动客户端模块的源代 码或者二进制代码。 ◆ 符合OCP原则的程序只通过增加代码来变化，而 不是通过更改现有代码来变化。 ◆ 实现OCP的关键是使用抽象来识别不同类之间的 共性和变化点，利用封装技术对变化点进行封装
OCP实例 Contact Manager if(o instanceof Email) Bcont actmech: Object return(Email)o) getAddress0: else if(o instanceof Phone retum(Phone)) getNumber0: eget ContactMech(contactmech: Object): Stringelse return n username: String 司 username: String egetNumber(: String ● getAddress0: String oPhone(number: String, username: String)Email(address: String,username:String) public String getContactlnfo(Cont actMech contactmech)( return contactmech getContactMech0 ContactManage ContactMech ontactmech. Cont actMech eget ContactInfo(contact mech: ContactMech): String getCont actMech0: String ntactMech0 Phone Ema umber String Username: String surname: String agetContact Mech0: String eget ContactMech0: String username: String) ⊙2008 BUPT TSEG 北京邮电大学通信软件工程中心
© 2008 BUPT TSEG 北京邮电大学 通信软件工程中心 17 OCP实例 Object
共京部電大学 10.33里氏替换原则 LSP(Liskov Substitution Principle) ◆子类应当可以替换父类并出现在父类能够 出现的任何地方。 ◆类A(客户类)调用类B(服务器类)的操 作A,由于类C是类B的子类,实际运行时 类C的实例可以替换类B的实例,完成操 作A的功能,而对于类A来讲,这种替换是 透明的。 类B 类A ◆操作A0 操作B0 类C ⊙2008 BUPT TSEG 北京邮电大学通信软件工程中心 18
© 2008 BUPT TSEG 北京邮电大学 通信软件工程中心 18 10.3.3里氏替换原则LSP(Liskov Substitution Principle) ◆ 子类应当可以替换父类并出现在父类能够 出现的任何地方。 ◆ 类A（客户类）调用类B（服务器类）的操 作A，由于类C是类B的子类，实际运行时 ，类C的实例可以替换类B的实例，完成操 作A的功能，而对于类A来讲，这种替换是 透明的
共京部電大学 10.34依赖倒置原则DP (Dependency Inversion Principle) a.高层模块不应该依赖于低层模块。二者 都应该依赖于抽象。 b。抽象不应该依赖于细节。细节应该依赖 于抽象。 ◆DP揭示启发式规则是:依赖于抽象,而不 序中所有的依 霸笑索终正李箝家类者接。 ◆应用程序中所编写的大多数具体类都是不 稳定的通过把启们隐在抽象接口的后 ⊙2008 BUPT TSEG 北京邮电大学通信软件工程中心 19
© 2008 BUPT TSEG 北京邮电大学 通信软件工程中心 19 10.3.4依赖倒置原则DIP (Dependency Inversion Principle) ◆ a．高层模块不应该依赖于低层模块。二者 都应该依赖于抽象。 ◆ b．抽象不应该依赖于细节。细节应该依赖 于抽象。 ◆ DIP揭示启发式规则是：依赖于抽象，而不 是具体的类。也就是说，程序中所有的依 赖关系应该终止于抽象类或者接口。 ◆ 应用程序中所编写的大多数具体类都是不 稳定的。通过把它们隐藏在抽象接口的后 面，可以隔离它们的不稳定性
壮京電大学 DIP举例 每个较高 Poli 次实现了 Mechanism 类都通过该抽黎接旦使用 浪务,这样 就不依赖于 低层。低层反而依赖于在高层中 的抽象 务接口 Mechani sm 〈 nterface》 Mechanism servic ⊙2008 BUPT TSEG 北京邮电大学通信软件工程中心 20
© 2008 BUPT TSEG 北京邮电大学 通信软件工程中心 20 DIP举例 Policy Mechanism Utility 每个较高层次都为它所需要的服 务声明一个抽象接口，较低的层 次实现了这些抽象接口，每个高 层类都通过该抽象接口使用下一 层的服务，这样高层就不依赖于 低层。低层反而依赖于在高层中 声明的抽象服务接口