设计模式1-六大思想
开放-封闭原则（开闭原则）
核心思想是：软件实体是可扩展的，但不可修改。
实现的步骤就是对抽象编程，不对具体编程，因为抽象相对比较稳定。
例如大话设计模式中举例，刚开始是做一个加法的操作，后续加入减法，乘法，除法等。所以刚开始需要设计的并不是加法，而是运算规则。
一般来讲，我们在这个时候设计的是
1 | public abstract int add(int a, int b); |
但是深入理解之后，这里应该设计成两数运算的方法。单纯的add并无法扩展，add仅仅是加法。
1 | public abstract int getResult(int a, int b); |
如此这样便可以不断的扩展，单纯设计加法也可，设计为减乘除皆可。
说实话此话说的容易，做起来贼难。Android 大部分还都是业务的抽象，一个presenter能够做的事情基本上都是处理业务，而如何抽象业务出来，说实话讲上去简单，但是抽象出来真的及其困难。
通过我多年的开发经验所得，认为这个抽象，最好还是脱离业务所设计。或者说基于一个大功能，大框架进行全方面的扩展。
而基础业务设计，最好不要太过抽象，否则太过高屋建瓴，对开发维护成本过大。（这也是业务开发的痛点，无法太过架构，离了架构，成长真的难）
单一职责原则
单一职责原则很好理解，就是一个类做一个事。
事实上类名很多时候就是代表这个类所做的事情。
然而理解深入，更容易发现难处。一个处理类，必然涉及很多功能点的处理，每个功能点的处理，单独独立出来当成一个职责处理者，这个实践中的复杂真的是极其难。
根据我多年的开发经验，我认为一个类，刚开始的设计，可以是单独的方法代码，一旦方法代码超出三个处理类型，一定要拓展成一个实体处理类。
依赖倒转原则
所谓依赖倒转，就是不依赖于实体类，而是逻辑处理依赖于接口。将实体对象抽象出来，而直接依赖于抽象完成逻辑的开发，而实体依赖于抽象完成自身的构建，因此就是依赖倒转
所以依赖倒转原则，可以说是面向接口编程，ood。
没有遵从依赖倒转原则，很容易导致模块与模块之间耦合度太高，降低生产力。
但是个人觉得Android开发，面向业务的时候大部分是mvp，mvc的类型，对于p层，说实话能抽的少之又少。但是对p层的封装的抽取倒是可以的。
类似于模式的切换，带来的p层一些公有的方法，可以做成抽象按照模式的变化做提供。
但是业务层全部面向接口，有点难。
接口隔离原则
使用多个隔离的接口会比使用一个聚合的接口好，出于降低耦合度的思想。
聚合的接口相对来讲可复用性低，大部分是为了抽象而抽象，而对聚合接口的拆封，不单单能产生单一指责原则，后期扩展亦会简单于聚合的接口
迪米特法则
迪米特法则即最小知道原则，即一个实体应该尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。
即一个对象应该对其他对象保持最少的了解。
还有一个比较通俗的看法，就是a如果依赖了b，同时b依赖了c，那么a对c的操作可以通过b完成，这样a只操作了b，却同时对b和c都有改动。
里氏替换原则
里氏替换原则：任何基类可以出现的地方，子类一定可以出现。
里氏替换原则作为对开闭原则的补充，开闭虽然抽象化了，但是抽象的具体步骤是由里氏替换原则来规定。
规定1：如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。
规定2：所有引用基类的地方必须能透明地使用其子类的对象。
通俗简单的说就是：子类可以扩展父类的功能，但不能改变父类原有的功能。