原文地址——L is for the Liskov Substitution Principle——Donn Felker
到了SOLID在Android中的实践第三部，如果你错过了前面精彩的部分，可以点开第一部——单一职责原则，第二部——开/闭原则。
利斯科夫替换原则
SOLID的L代表利斯科夫替换原则(Liskov Substitution Principle，LSP)，这是由Barbara Liskov在1987年会议上提出的重要课题，可以这样来描述
Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
它真正的含义是什么呢？
在你反复品读这个句子试图去理解其真正含义时，如我所料，会感到越来越迷惑。不幸的是，如果在你*里查询 Liskov Substitution Principle，会发现文章挖掘到更为深层次的各个计算机科学方面的知识。
写代码比理论更容易理解这个原则，在你写过的代码之中，很可能已经运用过LSP。
子类替换
Java属于静态类型语言。编译器能抓住并提示程序圆捣鼓的类型错误。例如把String 赋值给Long或相反，编译器能如实抛出这些错误，所以编译器是写出符合利斯科夫替换原则代码的利器。
假设要写个List，你肯定会写出过如下代码
// Get the ids somehow (loop, lookup, etc)
ArrayList<Integer> ids = getCustomerIds();
List<Customer> customers = customerRepository.getCustomersWithIds(ids);
这里的关键，getCustomersWithIds方法会不会返回List<Customer>，也许CustomerRepository已经写好了，但是后端仍未准备好，你决定使用接口隔离（Interface，或许是SOLID中的I） 。
public interface CustomerRepository {
List<Customer> getCustomersWithIds(List<Integer> ids);
}
public class CustomerRepositoryImpl implements CustomerRepository {
@Override
public List<Customer> getCustomersWithIds(List<Integer> ids) {
// Go to API, DB, etc and get the customers.
ArrayList<Customer> customers = api.getWholeLottaCustomers(ids);
return customers;
}
}
CustomerRepository 需要id来获取对应的Customer，把List<Integer>作为id列表参数，调用getCustomerIds时，使用了ArrayList<Integer>作为返回结果。等一等，CustomerRepository定义的返回值类型是List<Interger>而不是ArrayList<Integer>，这怎么没报错呢？
这就是利斯科夫替换原则。因为ArrayList<Integer>是List<Interger>的子类，所以当使用子类的实例替换父类的实例时，程序不会报错。
换而言之，在代码中我们使用抽象类List，同时使用子类进行替换，为什么就不会报错呢？
原因是CustomerRepository 是使用List来定义的接口，而ArrayList则是继承List，所以程序运行时，CustomerRepository 只会注意到是List而不会注意ArrayList。*的文章解释得很好，我这里引用一下
Liskov’s notion of a behavioral subtype defines a notion of substitutability for mutable […] objects; that is, if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program (e.g., correctness).
简略而言，我们可以使用任何继承List的子类来替换List而无需改动其他代码。
我很肯定你肯定写过成千上万类似的代码，这很常见，切合利斯科夫替换原则很简单，对不对？
更进一步，既然CustomerRepositoryImpl继承CustomerRepository，任何其他继承CustomerRepository的子类都是符合利斯科夫替换原则的。
怎么玩？
很简单，假设我们使用Dragger注入MockCustomerRepository，这是一个继承CustomerRepository的子类。代码只知道如何处理CustomerRepository的实例，因为MockCustomerRepository继承了CustomerRepository的所有特性，所以替换之后程序依旧正确。利斯科夫替换原则提供了巨大的可测试性和模拟性。
需要特定类型？
如果你熟悉Java，List<E>是继承Collection<E>的。
下面的编译结果如何？
// Get the ids somehow (loop, lookup, etc)
Collection<Integer> ids = getCustomerIds();
List<Customer> customers = customerRepository.getCustomersWithIds(ids);
为什么编译不通过？
getCustomersWithIds只接受List<Integer>，List是继承Collection的，但Collection不继承List，所以List是Collection，而Collection不一定是List。编译器会说，这是不兼容的。
返回类型，参数及其他
利斯科夫替换原则并不局限于参数类型，例如CustomerRepository返回ArrayList<Customer>
public interface CustomerRepository {
List<Customer> getCustomersWithIds(List<Integer> ids);
}
public class CustomerRepositoryImpl implements CustomerRepository {
@Override
public List<Customer> getCustomersWithids(List<Integer> ids) {
// Go to API, DB, etc and get the customers.
ArrayList<Customer> customers = api.getWholeLottaCustomers(ids);
return customers;
}
}
// Somewhere else in the program
List<Customer> customers = customerRepository.getCustomersWithIds(...);
调用者并不知道返回类型是ArrayList<Customer>，只需要知道返回类型是List<Customer>就足够了。我们可以定义自己的CustomerRepository子类，通过返回不同的List子类，例如LinkedList，从而实现不同的功能。
结论
利斯科夫替换原则很简单，你甚至无须知道它的名字。作为开发者，日常工作会经常运用这个原理，创造自己的接口并运用替换原则吧。
我们会在第四章讨论更多关于接口隔离的好处。
敬请期待。