面向对象设计的设计原则

　　里氏代换原则是依赖倒转原则的基础，依赖倒转原则是里氏代换原则的主要增补。

　　3.3 耦合（或者依赖）关系的种类：

　　零耦合（Nil Coupling）关系：两个类没有耦合关系。

　　详细耦合（Concrete Coupling）关系：发生在两个详细的（可实例化的）类之间，经由一个类对另一个详细类的直接引用造成。

　　抽象耦合（Abstract Coupling）关系：发生在一个详细类和一个抽象类（或接口）之间，使两个必须发生关系的类之间存有最大的天真性。

　　3.3.1 怎样掌握耦合

　　我们应该尽可能的制止实现继续，缘故原由如下：

　　1) 失去天真性，使用详细类会给底层的修改带来贫苦。

　　2) 耦合问题，耦合是指两个实体相互依赖于对方的一个量度。程序员天天都在（有意识地或者无意识地）做出影响耦合的决议：类耦合、API耦合、应用程序耦合等等。在一个用扩展的继续实现系统中，派生类是很是精密的与基类耦合，而且这种精密的毗连可能是被不期望的。如B extends A ，当B不全用A中的所有methods时，这时间，B挪用的要领可能会发生错误!

　　我们必须客观的评价耦合度，系统之间不行能总是松耦合的，那样一定什么也做不了。

　　3.3.2 我们决议耦合的水平的依据何在呢 ？

　　简朴的说，就是凭据需求的稳固性，来决议耦合的水平。对于稳固性高的需求，不容易发生转变的需求，我们完全可以把各种设计成紧耦合的（我们虽然讨论类之间的耦合度，但实在功效块、模块、包之间的耦合度也是一样的），由于这样可以提高效率， 而且我们还可以使用一些更好的手艺来提高效率或简化代码，例如c#中的内部类手艺。可是，若是需求极有可能转变，我们就需要充实的思量类之间的耦合问题，我们可以想出种种各样的措施来降低耦合水平，可是归纳起来，不外乎增添抽象的条理来隔离差别的类，这个抽象条理可以是抽象的类、详细的类，也可以是接口，或是一组的类。我们可以用一句话来归纳综合降低耦合度的头脑：“针对接口编程，而不是针对实现编程。”

　　在我们举行编码的时间，都市留下我们的指纹，如public的几多，代码的花样等等。 我们可以耦合怀抱评估重新构建代码的风险。由于重新构建现实上是维护编码的一种形式，维护中遇到的那些贫苦事在重新构建时同样会遇到。我们知道在重新构建 之后，最常见的随机bug大部门都是不妥耦合造成的 。

　　若是不稳固因素越大，它的耦合度也就越大。

　　某类的不稳固因素=依赖的类个数/被依赖的类个数

　　依赖的类个数＝ 在编译此类的时被编译的其它类的个数总和

　　3.3.3 怎样将大系统拆分成小系统

　　解决这个问题的一个思绪是将许多类荟萃成一个更高条理的单元，形成一个高内聚、低耦合的类的荟萃，这是我们设计历程中应该着重思量的问题！

　　耦合的目的是维护依赖的单向性，有时我们也会需要使用坏的耦合。在这种情形下，应当小心记载下缘故原由，以资助日后该代码的用户相识使用耦合真正的缘故原由。

　　3.4 怎样做到依赖倒转？

　　以抽象方式耦合是依赖倒转原则的要害。抽象耦合关系总要涉及详细类从抽象类继续，而且需要保证在任何引用到基类的地方都可以更换成其子类，因此，里氏代换原则是依赖倒转原则的基础。

　　在抽象条理上的耦合虽然有天真性，但也带来了分外的庞大性，若是一个详细类发生转变的可能性很是小，那么抽象耦合能施展的利益便十分有限，这时可以用详细耦合反而会更好。

　　条理化：所有结构优秀的面向工具构架都具有清晰的条理界说，每个条理通过一个界说优秀的、受控的接口向外提供一组内聚的服务。

　　依赖于抽象：建议不依赖于详细类，即程序中所有的依赖关系都应该终止于抽象类或者接口。只管做到：

　　1、任何变量都不应该持有一个指向详细类的指针或者引用。

　　2、任何类都不应该从详细类派生。

　　3、任何要领都不应该覆写它的任何基类中的已经实现的要领。

　　3.5 依赖倒转原则的优弱点

　　依赖倒转原则虽然很强盛，但却最不容易实现。由于依赖倒转的缘故，工具的建立很可能要使用工具工厂，以制止对详细类的直接引用，此原则的使用可能还会导致发生大量的类，对不熟悉面向工具手艺的工程师来说，维护这样的系统需要较好地明白面向工具设计。

 3/6   首页 上一页 1 2 3 4 5 6 下一页 尾页