by head first.

单一原则

定义：应该有且仅有一个原因引起类的变更。

单一原则适用于接口、类以及方法，对于接口，我们在设计的时候一定要做到单一，但对于实现类就需要多方面考虑。生搬硬套单一原则会引起类的剧增，给维护带来非常多的麻烦。而且过分细分类的职责也会人为地增加系统的复杂性。

最常见的就是Activity类，如果我们在Activity中进行网络请求操作，请求完毕又进行业务处理，处理之后通知View的刷新，这样做的话Activity就会变的十分臃肿，Activity的职责就是显示视图并处理与用户的交互，如何解决呢？抽离网络请求操作与业务操作，通过接口回调通知Activity视图的变更，推荐使用MVP模式。

对于单一原则，建议是接口一定要做的单一职责，类的设计尽量做到只有一个原因引起变化。

开闭原则

定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

开闭原则的定义已经非常明确地告诉我们：软件实体应该对扩展开放，对修改关闭，其含义是说一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。

比如现有一个类ProductFactory用来生产一堆产品：

public class ProductFactory {
    private final static List<Product> productList=new ArrayList<>();

    static {
        Product product=new Product();
        product.setPrice(10);
        product.setName("产品A");
        productList.add(product);
        product=new Product();
        product.setPrice(10);
        product.setName("产品B");
        productList.add(product);
    }

    public List<Product> getProduct(){
        return productList;
    }

}

客户端通过创建ProductFactory并调用getProduct方法就可以获取产品列表，看似非常完美，如果这个时候产品说我想获取产品A，然后过了几天由于产品效益不是很高，需要做打折处理，这个时候怎么办？是在ProductFactory类中新增方法还是直接在该方法中修改？由于业务的不断变化，造成该类被频繁修改。

使用开闭原则来解决，创建一个接口IProduct，内部约定一个规则：

public interface IProduct {
    List<Product> getProduct();
}

正常产品获取：

public class ProductFactory implements IProduct {

    private final static List<Product> productList=new ArrayList<>();

    static {
        Product product=new Product();
        product.setPrice(10);
        product.setName("产品A");
        productList.add(product);
        product=new Product();
        product.setPrice(10);
        product.setName("产品B");
        productList.add(product);
    }

    @Override
    public List<Product> getProduct() {
        return productList;
    }
}

客户端使用：

public class Client {
    public static void main(String[] args){
        IProduct productFactory=new ProductFactory();
        List<Product> productList=productFactory.getProduct();
    }
}

产品经理说我只需要产品A的产品，通过扩展来实现：

public class ProductAFactory implements IProduct {

    private final static List<Product> productList=new ArrayList<>();

    static {
        Product product=new Product();
        product.setPrice(10);
        product.setName("产品A");
        productList.add(product);
        product=new Product();
        product.setPrice(10);
        product.setName("产品B");
        productList.add(product);
    }

    @Override
    public List<Product> getProduct() {
        List<Product> list=new ArrayList<>();
        for(Product product:productList){
            boolean isProductA=product.getName().equals("产品A");
            if(isProductA){
                list.add(product);
            }
        }
        return list;
    }
}

客户端那边只需要把ProductFactory替换成ProductAFactory即可，即使产品说需要将产品进行打折处理，我们只需要创建打折类实现IProduct并实现getProduct方法进行打折处理。

里氏替换原则

定义：所有引用基类（父类）的地方必须能透明地使用其子类的对象。

里氏替换原则告诉我们，在软件中将一个基类替换成其子类对象，程序将不会产生任何错误和异常；反之则不行，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象。

子类的所有方法必须在父类中声明，或子类必须实现父类中声明的方法。根据里氏替换原则，为了保证系统的扩展性，在程序中通常使用父类来进行定义。

在运用里氏替换原则时，尽量把父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法。运行时，子类实例替换父类实例，我们可以方便地扩展系统的功能。

依赖倒置原则

定义：高层模块不应该依赖低层模块，两者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。

在Java中，抽象指接口或者抽象类，两者都不能直接被实例化。

细节就是实现类，实现接口或继承抽象类而产生的就是细节。

高层模块就是调用端，低层模块就是具体实现类。

依赖倒置的具体表现就是，模块间的依赖通过抽象发生，实现类之间不发生直接依赖关系，其依赖关系是通过接口或者抽象类产生的。

如果类与类直接依赖细节，那么就会直接耦合，如此一来当修改时，就会同时修改依赖者代码，限制了可扩展性。

迪米特原则

定义：一个软件实体应当尽可能少地与其他实体发生相互作用。

迪米特原则又被称为最少知识原则，通俗地讲，设计系统时尽量减少对象之间的交互，如果两个对象之间不必彼此直接通信，那么这两个对象就不应当发生任何直接的相互作用。

如果其中的一个对象需要调用另一个对象的某个方法，可以通过第三方转发这个调用。引入一个合理的第三者来降低现有对象之间的耦合度。

接口隔离原则

定义：一个类对另一个类的依赖应该建立在最小的接口上。

建立单一接口，不要建立庞大臃肿的接口；尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图建立一个很庞大的接口供所有依赖它的类调用。

接口尽量小，但要有限度。对接口进行细化可以提高程序设计的灵活性，但是如果过度的细化，则会造成接口数量过多，使设计复杂化。