作为一个非科班出身的程序猿，在最开始敲面向对象的代码时，没有“六大原则”的概念。后来看的书和敲的代码越来越多，“六大原则”逐渐熟悉起来，就如最开始只知道武功招数，后来经高人指点获得内功心法，有种豁然开朗的感觉。
设计模式的基本原则
1、单一职责原则
英文名：Single Responsibility Principle（SRP）
定义：一个类中应该是一组相关性很高的函数、数据的封装。
解释：单一，即划分一个类、一个函数的职责，两个完全不一样的功能就不应该放在一个类中。
2、开闭原则
英文名：Open Close Principle（OCP）
定义：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是，对于修改是封闭的。
解释：程序一旦完成，程序中一个类的实现只应该因错误而被修改，新的或者改变的特性应该通过新建不同的类实现，新建的类可以通过继承的方式来重用原类的代码。
3、里氏替换
英文名：Liskov Substitution Principle（LSP）
定义：所有引用基类的地方必须能透明地使用其子类的对象。
解释：简单来说，参数传递应使用基类。只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。
4、依赖倒置原则
英文名：Dependence Inversion Principle（DIP）
定义：一种特定的解耦形式，使得高层次的模块不依赖于低层次的模块的实现细节，依赖模块被颠倒了
解释：简单来说，依赖抽象，不要依赖具体。高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
5、接口隔离原则
英文名：Interface Segregation Principles（ISP）
定义：类间的依赖关系应该建立在最小的接口上。
解释：将非常庞大、臃肿的接口拆分成为更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。
6、迪米特原则
英文名：Law of Demeter（LOD）
定义：一个对象应该对其他对象有最少的了解
解释：简单来说，高内聚、低聚和。一个类应该对自己需要耦合或调用的类知道得最少，类的内部如何实现、如何复杂都与调用者或者依赖者没关系，调用者或者依赖者只需要知道他需要的方法即可，其他的我一概不关心。
工作上的应用
工作上应用比较多是：单一职责原则、里氏替换
1、单一职责原则
主要是在定义类方法的时候，多考虑这个原则。
这样帮助自己定义的方法功能单一明了，减少耦合，同时提高代码的复用性。
例如：页面加载数据的方法，一般分三个方法：
（1）获取数据 getData()，返回原始数据
（2）处理数据 processDate(Data rawData)，返回期望的数据类型
（3）显示数据 showData(), 显示数据在相关的UI上
PS：在最开始写代码时，写代码没有注意单一职责，一个方法包括好几个功能，不利于后续的扩展，改BUG也很痛苦。后续经同事指点，拆成多个单一功能的方法，后续用起来相当顺手：扩展方便，复用方便，更重要改BUG一针见效。
2、里氏替换
主要思想是面向接口编程。
这帮助自己更好的抽象代码、扩展业务需求。
例如：初始化RecyclerView的Adapter，可以写一个基类的数据ItemModel、一个基类的ViewHodler
public abstract class AbsItemModel {
//用于RecycleView.getItemViewType()，根据viewType创建不同的ViewHolder
public abstract int getType();
}
public abstract class AbsRecyclerViewHolder extends extends RecyclerView.ViewHolder {
public AbsRecyclerViewHolder(View itemView) {
super(itemView);
}
public abstract void onBindViewHolder(T model);
}
在实现Adapter的onBindViewHolder方法时调用这些基类
@Override
public void onBindViewHolder(RecyclerView.ViewHolder holder, int position) {
//List mDataList
AbsItemModel model = mDataList.get(position);
if (model == null) {
return;
}
AbsRecyclerViewHolder viewHolder = (AbsPersonRecyclerViewHolder) holder;
viewHolder.onBindViewHolder(model);
}
不同类型的ViewHolder继承这个基类ViewHolder，实现onBindViewHolder(T model)：根据数据model，显示相应的UI。
后续业务扩展，如果需要其他ViewHolder，那么直接继承基类，实现抽象方法即可。