敏捷软件开发依赖倒置原则与接口隔离原则.PPTVIP

* * Button 类直接依赖 Lamp 类。这个依赖关系意味着当 Lamp 类改变时，Button 类会受到影响。此外，想要重用 Button 来控制一个 Motor 对象是不可能的。在这个设计中，Button 控制着 Lamp 对象，并且也只能控制 Lamp 对象。 * * * * * * * * * * * * * * * * * * * * * * * DIP示例（三） 考虑设计一个控制熔炉调节器的软件。该软件可以从一个 I/O 通道中读取当前的温度，并通过向另一个 I/O 通道发送命令来指示熔炉的开或者关。 const?byte?THERMONETER=0x86;??const?byte?FURNACE=0x87;??const?byte?ENGAGE=1;??const?byte?DISENGAGE=0;??void?Regulate(double?minTemp,double?maxTemp)??{?????for(;;)?????{????????while?(in(THERMONETER)??minTemp)???????????wait(1);????????out(FURNACE,ENGAGE);????????????????while?(in(THERMONETER)??maxTemp)???????????wait(1);????????out(FURNACE,DISENGAGE);?????}??} DIP示例（三） 前面的代码根本不能重用于不同的控制硬件。重构后设计如下： DIP示例（三） Regulate 函数接受了两个接口参数。 Thermometer 接口可以读取温度，而 Heater 接口可以启动和停止。 这就倒置了依赖关系，使得高层的调节策略不再依赖于任何温度计或者熔炉的特定细节。该算法具有很好的可重用性。 ?void?Regulate(Thermometer?t,Heater?h,double?minTemp,?????double?maxTemp)??{????for(;;)????{while?(t.Read()??minTemp)???????wait(1);???????h.Engate();???????while?(t.Read()??maxTemp)??????????wait(1);???????h.Disengage();????}??} DIP原则实施要点 三种耦合关系 1.零耦合：如果两个类没有耦合关系，就称为零耦合。 2.具体耦合：具体性耦合发生在两个具体的（可实例化的）类之间，经由一个类对另一个具体类的直接引用造成的。 3.抽象耦合：抽象耦合关系发生在一个具体类和一个抽象类（或者Java接口）之间，使两个必须发生联系的类之间存有最大的灵活性。 应用DIP原则的设计尽量选择抽象耦合 DIP原则实施要点 因为DIP要求客户端依赖于抽象耦合。而依赖倒转的表述是：抽象不应当依赖于细节，细节应当依赖于抽象。这句话的另一种表述是：要针对接口编程，不要针对实现编程。（一个具体Java类应当只实现Java接口和抽象Java类中声明过的方法，而不应当给出多余的方法） 倒转依赖关系强调一个系统内的实体之间关系的灵活性。 DIP原则实施要点 由于一个抽象耦合关系总要涉及到具体类从抽象类继承，并且保证在任何引用到基类的地方都可以转换成其子类，因此，里氏代换原则是依赖倒转原则的基础。 在某些情况下，如果一个具体类发生变化的可能性很小，那么抽象耦合能发挥的好处便十分有限，这时使用具体耦合反而会更好，这时DIP原则就不适用了。 接口隔离原则（ISP） 如果类的接口不是内聚的（cohesive），就表示该类具有“胖”接口。类的“胖”接口可以分解成多组方法。每一组方法都服务于一组不同的客户程序。这样，一些客户程序可以使用一组成员函数，而其他客户程序可以使用其他组的成员函数。 ISP原则用来处理“胖”接口所具有的缺点。 ISP原则定义： ISP:不应该强迫客户依赖于它们不使用的方法. 接口污染 所谓接口污染就是为接口添加了不必要的职责。在接口中加一个新方法只是为了给实现类带来好处，以减少类的数目。持续这样做，接口就被不断污染，变胖。 实际上，类的数目根本不是什么问题，接口污染会带来维护和重用方面的问题。最常见的问题是我们为了重用被污染的接口，被迫实现并维护不必要的方法。 ISP示例 现在设计一个安全系统，有一些