面向对象设计七大原则

1. 单一职责原则（Single Responsibility Principle）

每个类应该专一于作一件事情。

2. 里氏替换原则（Liskov Substitution Principle）

超类存在的地方，子类是能够替换的。

3. 依赖倒置原则（Dependence Inversion Principle）

实现尽可能依赖抽象，不依赖具体实现。

4. 接口隔离原则（Interface Segregation Principle）

应当为客户端提供尽量小的单独的接口，而不是提供大的总的接口。

5. 迪米特法则（Law Of Demeter）

又叫最少知识原则，一个软件实体应当尽量少的与其余实体发生相互做用。

6. 开闭原则（Open Close Principle）

面向扩展开放，面向修改关闭。

7. 组合/聚合复用原则（Composite/Aggregate Reuse Principle CARP）

尽可能使用合成/聚合达到复用，尽可能少用继承。原则： 一个类中有另外一个类的对象。

细则

单一职责原则（Single Responsibility Principle）

由于：

能够下降类的复杂度，一个类只负责一项职责，其逻辑确定要比负责多项职责简单的多；提升类的可读性，提升系统的可维护性；变动引发的风险下降，变动是必然的，若是单一职责原则遵照的好，当修改一个功能时，能够显著下降对其余功能的影响。须要说明的一点是单一职责原则不仅是面向对象编程思想所特有的，只要是模块化的程序设计，都适用单一职责原则。

因此：

从大局上看Android中的Paint和Canvas等类都遵照单一职责原则，Paint和Canvas各司其职。

里氏替换原则（Liskov Substitution Principle）

由于：

里氏替换原则告诉咱们，在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，若是一个软件实体使用的是一个子类对象的话，那么它不必定可以使用基类对象。里氏替换原则是实现开闭原则的重要方式之一，因为使用基类对象的地方均可以使用子类对象，所以在程序中尽可能使用基类类型来对对象进行定义，而在运行时再肯定其子类类型，用子类对象来替换父类对象。

因此：

使用里氏替换原则时须要注意，子类的全部方法必须在父类中声明，或子类必须实现父类中声明的全部方法。尽可能把父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实如今父类中声明的方法，运行时，子类实例替换父类实例，咱们能够很方便地扩展系统的功能，同时无须修改原有子类的代码，增长新的功能能够经过增长一个新的子类来实现。

从大局看Java的多态就属于这个原则。

依赖倒置原则（Dependence Inversion Principle）

由于：

具体依赖抽象，上层依赖下层。假设B是较A低的模块，但B须要使用到A的功能，这个时候，B不该当直接使用A中的具体类；而应当由B定义一抽象接口，并由A来实现这个抽象接口，B只使用这个抽象接口；这样就达到了依赖倒置的目的，B也解除了对A的依赖，反过来是A依赖于B定义的抽象接口。经过上层模块难以免依赖下层模块，假如B也直接依赖A的实现，那么就可能形成循环依赖。

因此：

采用依赖倒置原则能够减小类间的耦合性，提升系统的稳定性，减小并行开发引发的风险，提升代码的可读性和可维护性。

从大局看Java的多态就属于这个原则。

接口隔离原则（Interface Segregation Principle）

由于：

提供尽量小的单独接口，而不要提供大的总接口。暴露行为让后面的实现类知道的越少越好。譬如类ProgramMonkey经过接口CodeInterface依赖类CodeC，类ProgramMaster经过接口CodeInterface依赖类CodeAndroid，若是接口CodeInterface对于类ProgramMonkey和类CodeC来讲不是最小接口，则类CodeC和类CodeAndroid必须去实现他们不须要的方法。将臃肿的接口CodeInterface拆分为独立的几个接口，类ProgramMonkey和类ProgramMaster分别与他们须要的接口创建依赖关系。也就是采用接口隔离原则。

因此：

创建单一接口，不要创建庞大的接口，尽可能细化接口，接口中的方法尽可能少。也就是要为各个类创建专用的接口，而不要试图去创建一个很庞大的接口供全部依赖它的类去调用。依赖几个专用的接口要比依赖一个综合的接口更灵活。接口是设计时对外部设定的约定，经过分散定义多个接口，能够预防外来变动的扩散，提升系统的灵活性和可维护性。

从大局来讲Java的接口能够实现多继承就是接口隔离原则的基础保障。

迪米特法则（Law Of Demeter）

由于：

类与类之间的关系越密切，耦合度也就愈来愈大，只有尽可能下降类与类之间的耦合才符合设计模式；对于被依赖的类来讲，不管逻辑多复杂都要尽可能封装在类的内部；每一个对象都会与其余对象有耦合关系，咱们称出现成员变量、方法参数、方法返回值中的类为直接的耦合依赖，而出如今局部变量中的类则不是直接耦合依赖，也就是说，不是直接耦合依赖的类最好不要做为局部变量的形式出如今类的内部。

因此：

一个对象对另外一个对象知道的越少越好，即一个软件实体应当尽量少的与其余实体发生相互做用，在一个类里能少用多少其余类就少用多少，尤为是局部变量的依赖类，能省略尽可能省略。同时若是两个类没必要彼此直接通讯，那么这两个类就不该当发生直接的相互做用。若是其中一个类须要调用另外一个类的某一方法的话，能够经过第三者转发这个调用。

从大局来讲Android App开发中的多Fragment与依赖的Activity间交互通讯遵照了这一法则。

开闭原则（Open Close Principle）

由于：

开放封闭原则主要体如今对扩展开放、对修改封闭，意味着有新的需求或变化时，能够对现有代码进行扩展，以适应新的状况。软件需求老是变化的，世界上没有一个软件的是不变的，所以对软件设计人员来讲，必须在不须要对原有系统进行修改的状况下，实现灵活的系统扩展。

因此：

能够经过Template Method模式和Strategy模式进行重构，实现对修改封闭，对扩展开放的设计思路。 
封装变化，是实现开放封闭原则的重要手段，对于常常发生变化的状态，通常将其封装为一个抽象，拒绝滥用抽象，只将常常变化的部分进行抽象。

组合/聚合复用原则（Composite/Aggregate Reuse Principle CARP）

由于：

其实整个设计模式就是在讲如何类与类之间的组合/聚合。在一个新的对象里面经过关联关系（包括组合关系和聚合关系）使用一些已有的对象，使之成为新对象的一部分，新对象经过委派调用已有对象的方法达到复用其已有功能的目的。也就是，要尽可能使用类的合成复用，尽可能不要使用继承。

若是为了复用，便使用继承的方式将两个不相干的类联系在一块儿，违反里氏代换原则，哪是生搬硬套，忽略了继承了缺点。继承复用破坏数据封装性，将基类的实现细节所有暴露给了派生类，基类的内部细节经常对派生类是透明的，白箱复用；虽然简单，但不安全，不能在程序的运行过程当中随便改变；基类的实现发生了改变，派生类的实现也不得不改变；从基类继承而来的派生类是静态的，不可能在运行时间内发生改变，所以没有足够的灵活性。

因此：

组合/聚合复用原则可使系统更加灵活，类与类之间的耦合度下降，一个类的变化对其余类形成的影响相对较少，所以通常首选使用组合/聚合来实现复用；其次才考虑继承，在使用继承时，须要严格遵循里氏代换原则，有效使用继承会有助于对问题的理解，下降复杂度，而滥用继承反而会增长系统构建和维护的难度以及系统的复杂度，所以须要慎重使用继承复用。

总结

至此，七大基本原则介绍完毕，很空洞，须要联系Java与android代码去仔细体会琢磨。