温馨提示：阅读本文需要4-5分钟（少量代码）
今天，我们来解决一个问题：
如何写出优秀的代码？设计模式六大原则告诉你
人生一切难题，知识给你答案。
==单一原则==
定义：应该有且仅有一个原因引起类的变更。
单一原则适用于接口、类以及方法，对于接口，我们在设计的时候一定要做到单一，但对于实现类就需要多方面考虑。生搬硬套单一原则会引起类的剧增，给维护带来非常多的麻烦。而且过分细分类的职责也会人为地增加系统的复杂性。
最常见的就是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中，抽象指接口或者抽象类，两者都不能直接被实例化。
细节就是实现类，实现接口或继承抽象类而产生的就是细节。
高层模块就是调用端，低层模块就是具体实现类。
依赖倒置的具体表现就是，模块间的依赖通过抽象发生，实现类之间不发生直接依赖关系，其依赖关系是通过接口或者抽象类产生的。
如果类与类直接依赖细节，那么就会直接耦合，如此一来当修改时，就会同时修改依赖者代码，限制了可扩展性。
==迪米特原则==
定义：一个软件实体应当尽可能少地与其他实体发生相互作用。
迪米特原则又被称为最少知识原则，通俗地讲，设计系统时尽量减少对象之间的交互，如果两个对象之间不必彼此直接通信，那么这两个对象就不应当发生任何直接的相互作用。
如果其中的一个对象需要调用另一个对象的某个方法，可以通过第三方转发这个调用。引入一个合理的第三者来降低现有对象之间的耦合度。
==接口隔离原则==
定义：一个类对另一个类的依赖应该建立在最小的接口上。
建立单一接口，不要建立庞大臃肿的接口；尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图建立一个很庞大的接口供所有依赖它的类调用。
接口尽量小，但要有限度。对接口进行细化可以提高程序设计的灵活性，但是如果过度的细化，则会造成接口数量过多，使设计复杂化。
