1.单一职责原则
就一个类而言，应该仅有一个引起它变化的原因。也就是说，一个类中应该是一组相关性很高的函数、数据的封装。一个类只负责一个职责，不要存在多于一个导致类变更的原因。
比如一个类记录一些食品的名称，但同时又记录食品的做法。前者属于业务对象，后者属于业务逻辑，根据单一职责原则，需要将业务和数据分开。
未遵循单一职责原则：
public class Foods {
private String fish;
private String meat;
public String getFish() { return fish;}
public void setFish(String fish) {this.fish = fish;}
public String getMeat() { return meat;}
public void setMeat(String meat) {
this.meat = meat;
}
public void RedCookedFish(){
//do something...
}
public void RedCookedMeat(){
//do something...
}
}
遵循单一职责原则（分为两个类）：
public class Foods {
private String fish;
private String meat;
public String getFish() { return fish; }
public void setFish(String fish){this.fish = fish;}
public String getMeat() { return meat; }
public void setMeat(String meat) {
this.meat = meat;
}
}
public class Practices {
public void RedCookedFish(){
//do something...
}
public void RedCookedMeat(){
//do something...
}
}
2.开闭原则
软件中的对象（类、模块和函数等）应该对于扩展是开放的，对于修改是关闭的。
在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，我们并不想在原来的功能类去修改，导致破坏原来的逻辑，以至于出现新的BUG，所以在设计系统时尽量通过扩展的方式实现新的功能，也就是要好好利用继承和接口。
比如有一个动物，有姓名和运动方式两种属性，当它成年时，需要结交异性，又需要增加繁衍后代的功能，就可以通过继承或者接口的方式进行扩展新功能，遵守开闭原则。
public class Animal {
private String mName;
private String mMovementMode;
public Animal(String mName,String mMovementMode){
this.mName = mName;
this.mMovementMode = mMovementMode;
}
public String getmName() { return mName;}
public String getmMovementMode() {
return mMovementMode;
}
}
public class Multiply extends Animal {
public Multiply(String mName, String mMovementMode) {
super( mName, mMovementMode );
}
public void MultiplyMethod(){
//do something...
}
}
3.里氏替换原则
所有引用基类的地方必须能透明的使用其子类。通俗的说，就是只要父类能出现的地方子类就可以出现，而且替换为子类以后不会出现任何错误或异常。反过来就不行了，子类出现的地方父类不一定能适应。
如果对每一个类型为 T1的对象o1，都有类型为T2的对象o2，使得以 T1定义的所有程序P 在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。
要实现里氏替换原则，一般需要一个抽象的父类，父类中定义了子类的公共方法，子类继承或实现父类以后扩展不同的功能，这样一来可以实现根据不同的需要来应用对应的子类，从而达到应用不同的功能的目的，程序的扩展性大大增强。同时这也体现了开闭原则，即当需要增加新功能时，只要继承或实现父类，实现新增的功能后就达到了扩展的目的，而不是直接修改原来的代码，也即对扩展开放，对修改封闭。
举个例子，Android中的Window与View的关系:
// 窗口类
public class Window {
public void show(View child){
child.draw();
}
}
// 建立视图抽象，测量视图的宽高为公用代码，绘制交给具体的子类
public abstract class View {
public abstract void draw() ;
public void measure(int width, int height){
// 测量视图大小
}
}
// 按钮类的具体实现
public class Button extends View {
public void draw(){
// 绘制按钮
}
}
// TextView的具体实现
public class TextView extends View {
public void draw(){
// 绘制文本
}
}
上述示例中，Window依赖于View，而View定义了一个视图抽象，measure是各个子类共享的方法，子类通过覆写View的draw方法实现具有各自特色的功能，在这里，这个功能就是绘制自身的内容。任何继承自View类的子类都可以设置给show方法，也就我们所说的里氏替换。通过里氏替换，就可以自定义各式各样、千变万化的View，然后传递给Window，Window负责组织View，并且将View显示到屏幕上。
里氏替换原则的核心原理是抽象，抽象又依赖于继承这个特性，在OOP当中，继承的优缺点都相当明显。
4.依赖倒置原则
依赖倒置原则在Java中的表现就是：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。
依赖倒置原则指代了一种特定的解耦形式，使得高层的模块不依赖于低层的模块的实现细节的目的，依赖模块被颠倒了。
依赖倒置原则在 Java 语言中的表现就是：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。也就是面向接口编程，或者说是面向抽象编程，这里的抽象指的是接口或者抽象类。
如果在类与类直接依赖于细节，那它们之间就有直接的耦合，当具体实现需要变化时，意味着在这同时修改依赖者的代码，并且限制了系统的可扩展性。
依赖倒置原则的几个关键点：
①高层模块（调用端）不应该依赖低层模块（具体实现类），两者都应该依赖其抽象；
②抽象不应该依赖细节（实现类）；
③细节应该依赖抽象。
也就是说依赖抽象而不依赖具体的实现。
比如现阶段热门的编程语言,java,c,python等，但随着时间的推移，随着科技的发展，会根据需求不同，产生新的语言。如果要在一个类中一个个添加，那样太麻烦，使用接口进行配置，则会简单很多。
未遵守依赖导致原则：
class C{
public String get(){
return "C";
}
}
class Java{
public String get(){
return "Java";
}
}
class Python{
public String get(){
return "Python";
}
}
class GetLanguage{
public GetLanguage(){
}
public void getLanguage(C c){
Log.d( "Language",c.get() );
}
public void getLanguage(Java java){
Log.d( "Language",java.get() );
}
}
GetLanguage language = new GetLanguage();
language.getLanguage( new C() );
language.getLanguage( new Java() );
遵守依赖导致原则：
定义接口
public interface ILanguage {
String get();
}
public class Language {
public void getLanguage(ILanguage iLanguage){
Log.d( "Language",iLanguage.get() );
}
}
Language language = new Language();
language.getLanguage( new ILanguage() {
@Override
public String get() {
return "C";
}
} );
5.接口隔离原则
客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
也就是说，一个类只需要实现自己需要的方法，不相干的方法不需要实现。
接口隔离原则就是让客户端依赖的接口尽可能的小。就是在依赖倒置原则的基础上，增加一个最小化依赖的原则。
比如一个接口实现动物所有的运动方式，比如：跑、爬、游、飞、跳。老鹰就只需要实现飞，狗就只需要实现跑，但是实现这个接口的话，必须实现所有方法，就会很臃肿，并且有的方法不需要实现。我们只需要将他们拆分成四个接口，不同的动物，实现不同的运动方式即可。
未遵守接口隔离原则：
public interface IAnimal {
void run();
void swim();
void climb();
void fly();
}
class Dog implements IAnimal{
@Override
public void run() {
}
@Override
public void swim() {
}
@Override
public void climb() {
}
@Override
public void fly() {
}
}
遵守接口隔离原则：
public interface Swim{
void swim();
}
public interface Run{
void run();
}
public interface Climb{
void climb();
}
public interface Fly{
void fly();
}
class Dog implements Run{
@Override
public void run() {
}
}
6.迪米特原则
一个对象应该对其他对象保持最少的了解。
一个类应该对自己需要耦合或调用的类知道得最少，类的内部如何实现、如何复杂都与调用者或者依赖者没关系，调用者或者依赖者只需要知道他需要的方法即可，其他的一概不关心。类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
假如一个类实现了加减乘除四个方法，同时在加减乘除方法内实现了对进行运算的数值进行类型判断。类型判断中又实现了范围判断。我们只需要将加减乘除四个方法暴露即可，其余方法不需要暴露。
public class Operation {
public Object Add(Object num1,Object num2){
Object flag = JudgeType(num1,num2);
int num = (Integer) flag;
switch (num){
case 0:
return (Integer)num1 + (Integer)num2;
case 1:
return (Double)num1 + (Double) num2;
default:
return null;
}
}
private void Sub(Object num1,Object num2){
}
private void Ride(Object num1,Object num2){
}
private void Division(Object num1,Object num2){
}
private Object JudgeType(Object num1,Object num2){
if (num1 instanceof Integer){
return 0;
}else if (num1 instanceof Double){
return 1;
}
return 3;
}
}
Operation operation = new Operation();
Log.d( "Result=",operation.Add( 1,1 )+"" );