需求分析与系统设计课件6最少依赖原则.pptVIP

6.最少依赖原则 Composite?Reuse?Principle 合成复用原则 Has-a 关系 实例：窗口类与矩形类 代码复用、委派 继承 Vs 合成 Composite?Reuse?Principle2 Why extends is evil JDK的错误 设计Stack －1 Law?of?Demeter 迪米特法则 1、耦合的一般介绍 低耦合 2、Law?of?Demeter 迪米特法则 老子：论圣人之治 实例：X、Y、Z 方案1 ：违反迪米特原理 方案2 ：Y工厂 方案3 ：Y转发消息 迪米特法则的狭义解读 狭义LoD缺点 倚赖关系是传递的 广义的迪米特法则 不变类 不变类 条件 Demeter OOD之七大原理 强内聚 Single Responsibility Principle 实例：矩形系统 实例：调制解调器 SRP要点 Interface Segregation Principle 接口隔离原则2 解决方法-分离接口 实例：能超时报警的门 AlarmDoor 接口与抽象类 语法层面 设计理念层面 单一职责原理 There should never be more than one reason for a class to change. 就一个类而言，应该仅有一个引起它变化的原因 . 一个GUI系统的设计。要求： 可以计算矩形的面积—— area()方法 并在屏幕上显示 —— draw()方法 几何计算系统调用Rectangle计算面积 GUI系统调用Rectangle绘制在屏幕上 在编译几何计算系统时还需要编译进图形代码；需要更换显示系统时还需要重新测试所有几何计算系统…… 解决方法：将计算和绘制的职责分别放入CulRectangle和GraphRectangle中 调制解调器就有4个功能 ，但职责却是2个：连接管理（dial and hangup）和数据通信(send and recv)。 public interface Modem{ void dialog (String pno); void hangup (); void send (char c); void recv (); } 如果应用程序的变化会影响连接管理方法的签名[dialog(String pno)变成dialog (long pno)]，所有使用了数据通信职责[send和recv]类却必须要重新编译。 “一个职责的变化可能会或者抑制这个类的其他职责的能力。便如你改变了一个多职责类的一个职责，你必须测试所有其他使用这个类另外的职责的程序，如果忘记这样，可能会导致不可预测的失败 ” 一个类的职责是指引起该类变化的原因，如果一个类具有一个以上的职责，那么就会有多个不同的原因引起该类变化。 其实质就是耦合了多个互不相关的职责，就会降低这个类的内聚性。 软件设计真正要做的重要工作，就是发现职责，并把它们互相分离。 最少职责原则。最少指的是够用，单一更细。太过多的划分会造成“过度设计” 。 接口隔离原则The Interface Segregation Principle (ISP)： clients should not be forced to depend upon interfaces that they do not use。 不要强迫客户依赖于它们不用的接口。 一个职责常常由一系列的服务接口去表达，如果系统涉及多个职责，我们应该让接口隔离开来。 Favour many client specific interfaces over one general purpose interface 使用多个专门的接口比使用单一的总接口要好。 一个类对另一个类的依赖性，应当是建立在最小的接口之上。 没有关系的接口合并在一个class/interface中，会形成一个臃肿的接口集——接口污染（Interface Contamination） 1、利用委托分离接口。如Adapter模式 2、利用多继承分离接口。 abstract class Door { void open(); void close(); void timeOut(); } 所有的门都需要超时报警吗 ？ public abstract class Door{ abstract void open(); abstract void close(); } public interface Alarm{ void timeOut(); } public class AlarmDoor extends Door implements Alarm{