走向面向对象的六大原则--里氏替换原则

面向对象编程的六大原则

• 单一职责原则
• 开闭原则
• 里氏替换原则
• 依赖倒置原则
• 接口隔离原则
• 迪米特原则

---

让程序有更好的拓展性--里氏替换原则

里氏替换原则的英文全称是Liskov Substiution Principle。缩写是LSP。
LSP的第一种定义是：如果对没一个类型为S的对象O1，都有类型为T的对象O2，使得以T定义的所有程序P在所有的对象O1都代换成O2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。
上面的描述是不是看过去就头大？是的，就像后悔的作者一样，头大！那么我们来看看第二种定义。
LSP的第二种定义是:所有引用基类的地方必须能透明地使用其子类的对象。
正如我们知道的，面向对象的三大特性是：继承、封装、多态，里氏替换原则就是依赖于继承和多态两大特性。简单地说，就是父类能出现的地方子类就可以出现，而且替换成子类也不会出现任何错误或者异常，而使用者也无需知道是父类还是子类。但是有子类的地方不一定适用于所有父类。其实总结就两个字抽象。
此处我们使用Android中Window与View的关系进行示例：

public class Window {
    public void showView(View child) {
        child.draw();
    }
}

public abstract class View {
    public abstract void draw();

    public void measure(int width, int height) {
        // 调整视图大小
    }
}

public class Button extends View {
    @Override
    public void draw() {
        // 绘制按钮
    }
}

public class TextView extends View {
    @Override
    public void draw() {
        // 绘制文本
    }
}

在上述实例中，Window依赖于View，而View定义了一个视图抽象，measure是各个子类所共享的方法，子类通过覆写draw方法实现各具特色的功能。所有继承自View类的子类都可以设置给show方法，这就是所谓的里氏替换原则。
通过里氏替换原则就可以自定义各式各样千变万化的View，然后传输给Window，Window负责将View展示到屏幕上。
里氏替换原则的和心愿礼是抽象，抽象又依赖于继承这个特性，在OOP中，继承的优缺点都很明显：
优点：

• 提高代码的可拓展性。
• 子类和父类基本相似，但是保留自我特性。
• 代码复用，减少类的数量和代码量，每个子类都可以使用父类的方法和属性。
  缺点：
• 继承就必须拥有父类的方法和属性。
• 可能造成子类的代码冗余，因为它必须拥有父类的属性和方法，可能会降低子类的灵活性。

---

此时我们回过头看上一篇文章开闭原则中的ImageLoader类中的setImageCache方法，即很好地反映了里氏替换原则。

//设置为磁盘缓存
imageLoader.setmImageCache(new DiskCache());
//设置为内存缓存
imageLoader.setmImageCache(new MemoryCache());
//设置为双缓存
imageLoader.setmImageCache(new DoubleCache());
//设置为自定义缓存
imageLoader.setmImageCache(new ImageCache() {
    @Override
    public Bitmap get(String url) {
        return null;
    }

    @Override
    public void put(String url, Bitmap bitmap) {

    }
});

在上述代码中，我们可以使用任何一个实现了ImageCache接口的类去实现缓存功能，同时也可以直接实现ImageCache接口去自定义我们的缓存。
想象一下，如果此处我们不能这样，只能通过不同的方法去设置我们的缓存方式，此时便会增加相当多的代码量，并且影响到代码的简洁和稳定性和拓展性。比如上一章中的setDiskCacheEnable方法，这种方式明显是不可取的。
里氏替换原则就为这类问题提供了指导，也就是建立抽象，通过抽象来建立规范，具体实现在运行时取代抽象，保证了系统的拓展性和灵活性。开闭原则和里氏替换原则一般情况下是生死相依不离不弃的，通过里氏替换原则打到对拓展开放，对修改关闭的效果。
本章和上章内容其实都抢掉了一个OOP的重要特性，抽象。在开发过程中运用好抽象，是走向代码优化的第一步！