oo设计原则

软件维护时间将要占软件生命周期的90%，说明软件的可扩展性是十分重要的

遵守设计原则将会极大提高软件的可维护性和可扩展性，使我们有时间专注于更重要的部分

每一个设计模式都体现了一个或多个设计原则：

一，找出应用中可能变化之处，把他们独立出来，不要和那些不需要变化的代码混在一起（封装）

    如果每次新的需求一来，都会使某部分的代码发生变化，那么就可以确定这部分代码需要被独立出来，和其他稳定代码有所区分

    判断哪里将发生变化是很难的，特别要注意不要过度设计

二，针对接口编程，而不是针对实现编程（解耦）

    这里的接口不是单指interface，而是指超类型，超类型包含interface和abstract类

 

三，多用组合，少用继承

   继承在某些情况下会带来很多问题，极大降低程序的可扩展性，复用性，使程序难于维护（参考模式：Strategy Pattern）

 

四，为了交互对象的松耦合设计而努力

    松耦合有助于建立充满弹性的oo系统，能够应对变化，因为对象之间的依赖性降到了最低，能够极大的提高程序的可扩展性

 

五，开放-关闭原则：类应该对扩展开放，对修改关闭（参考模式：Decorate Pattern）

    对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况

    对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对类进行任何修改

    在所有地方都遵守“开放-关闭原则”是一种浪费（会引入新的抽象层次并增加代码复杂度），只需要在代码中最有可能变化的部分使用该原则即可

 

六，依赖倒置原则（Dependency Inversion Principle）：要依赖抽象，不要依赖具体类（参考模式：Factory Method Pattern）

    高层组件和底层组件都依赖于抽象

    设计类时，从顶层组件开始，然后从上至下分析、创建顶层组件所需的底层组件，这种思考方式经常会导致顶层组件、底层组件之间的耦合

    从底层组件开始，通过底层组件的共同特征抽象出抽象类，然后再回过头来设计顶层组件，由于已经有一个抽象类，顶层组件无需面向具体的底层组件，依靠一个工厂获取特定的底层组件即可，这样就实现了顶层、底层组件之间的解耦。由下而上的设计、思考方式被称为倒置

 

七，最少知识原则（参考模式：Facade Pattern）

    不要让太多的类耦合在一起，以免修改系统中的一些部分，会影响系统中的另一些部分

    如果过多类耦合在一起，则系统就会变得易碎，并且需要消耗更多的精力维护，并且由于过于复杂，后续维护人员也将消耗更多的精力

原则与模式可以应用于软件开发周期的任何阶段（不仅仅在设计阶段，编码、重构时都会用到它们）