面向对象的六大原则——让代码更优美

导语

让你的代码更加优美。

主要内容

• 单一职责原则——优化代码的第一步
• 开闭原则——让程序更稳定灵活
• 里氏替换原则——构建扩展性更好的系统
• 依赖倒置原则——让项目拥有变化的能力
• 接口隔离原则——让系统有更高的灵活性
• 迪米特原则——更好的可扩展性

具体内容

单一职责原则

单一职责原则的英文名名称是Single Responsibility Principle，缩写是SRP。SRP的定义是：就一个类而言，应该仅有一个引起它变化的原因。简单来说，一个类中应该是一组相关性很高的函数、数据的封装。

比如Pear是一家电子产品商，它要生产pad，phone，watch等设备，但是有一些重复的功能，如果分别设计一套，很显然并不划算，那么接口定义上我们就可以根据功能划分设定单一职责的接口：

接口的定义

//可以拨打电话
interface Callable{
    void call ();
}

//可以触摸控制
interface Touchable{
    void touch();
}

//可以消息提醒
interface MessagePromptable{
    void prompt();
}

//可以接入键盘
interface KeyBoardMatchable{
    void match();
}

实现接口的类依旧单一职责

class StandardCall implements Callable{

    @Override
    public void call() {
        System.out.println("Call to somebody!");
    }
}

class StandardTouch implements Touchable{

    @Override
    public void touch() {
        System.out.println("touch to press the button!");
    }
}

class StandardPromt implements MessagePromptable{

    @Override
    public void prompt() {
        System.out.println(" someone contact to you,sir!");
    }
}

class StandardMatch implements KeyBoardMatchable{

    @Override
    public void match() {
        System.out.println("The keyBoard is ready to work!");
    }
}

产品的生产
我们如果基于我们现有的技术生产一部手机，那么我们需要它能打电话，触屏控制和消息提醒：

//在声明这台手机时我们就明确知道了它的功能
class MyPhone implements Callable, MessagePromptable, Touchable{

    //无需重复研发已有的技术，直接装载即可
    private Callable caller = new StandardCall();
    private MessagePromptable prompter = new StandardPromt();
    private Touchable toucher = new StandardTouch();

    @Override
    public void call() {
        caller.call();
    }

    @Override
    public void prompt() {
        prompter.prompt();
    }

    @Override
    public void touch() {
        toucher.touch();
    }
}

public class SRPTest {
    public static void main ( String [] args ){
        MyPhone phone = new MyPhone();
        phone.call();
        phone.prompt();
        phone.touch();
    }
}

假如我们需要出一款新的手机，但是我们只是拥有了新的呼叫技术，那么只需要在实现这项技术时继承Callable接口，然后在之前手机new的Callable的具体实例换成新的技术即可，只需要修改一行代码，是不是感觉棒棒的。职责的单一，对于我们对于现有类的修改造成的影响有了约束。

那么如果我想生产一个Pad呢，同理啊，只需要在已有技术上装载即可啊，Pad类依旧只是单一的整合技术形成产品的职责，整合成产品和研发出技术的职责分离，为我们的类的拓展带来了方便。

class MyPad implements Touchable,KeyBoardMatchable{

    Touchable toucher = new StandardTouch();
    KeyBoardMatchable matcher = new StandardMatch();

    @Override
    public void match() {
        toucher.touch();
    }

    @Override
    public void touch() {
        matcher.match();
    }
}

下面一个例子，我们的接口依旧单一职责，但是接听和拨打电话的功能往往是不可分的，他们会同时发生变化，所以我们可以提供一个同时继承两个接口的实现类。

class CallAndPrompt implements Callable,MessagePromptable{

    @Override
    public void call() {
        System.out.println("Hello, I have some thing to tell you!");
    }

    @Override
    public void prompt() {
        System.out.println("Hello,what do you want to tell me!");
    }
}

//在声明这台手机时我们就明确知道了它的功能
class MyPhone implements Callable,MessagePromptable,Touchable{

    //无需重复研发已有的技术，直接装载即可
    private Callable caller = new CallAndPrompt();
    //不同的接口调用同一个实现类的不同功能
    private MessagePromptable prompter = (MessagePromptable)caller;
    private Touchable toucher = new StandardTouch();

    @Override
    public void call() {
        caller.call();
    }

    @Override
    public void prompt() {
        prompter.prompt();
    }

    @Override
    public void touch() {
        toucher.touch();
    }
}

开闭原则

开闭原则的英文全称是Open Close Principle，缩写是OCP，它是Java世界里最基础的设计原则，它指导我们如何建立一个稳定的、灵活的系统。开闭原则的定义是：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是，对于修改是封闭的。

优点：按照OCP原则设计出来的系统，降低了程序各部分之间的耦合性，其适应性、灵活性、稳定性都比较好。当已有软件系统需要增加新的功能时，不需要对作为系统基础的抽象层进行修改，只需要在原有基础上附加新的模块就能实现所需要添加的功能。增加的新模块对原有的模块完全没有影响或影响很小，这样就无须为原有模块进行重新测试。

如何实现“开-闭”原则
在面向对象设计中，不允许更改的是系统的抽象层，而允许扩展的是系统的实现层。换言之，定义一个一劳永逸的抽象设计层，允许尽可能多的行为在实现层被实现。
解决问题关键在于抽象化，抽象化是面向对象设计的第一个核心本质。
对一个事物抽象化，实质上是在概括归纳总结它的本质。抽象让我们抓住最最重要的东西，从更高一层去思考。这降低了思考的复杂度，我们不用同时考虑那么多的东西。换言之，我们封装了事物的本质，看不到任何细节。
在面向对象编程中，通过抽象类及接口，规定了具体类的特征作为抽象层，相对稳定，不需更改，从而满足“对修改关闭”；而从抽象类导出的具体类可以改变系统的行为，从而满足“对扩展开放”。
对实体进行扩展时，不必改动软件的源代码或者二进制代码。关键在于抽象。

接口的定义

public interface ImageCache {
    public Bitmap get(String url);
    public void put(String url, Bitmap bmp);
}

实现接口

// 内存缓存MemoryCache类
public class MemoryCache implements ImageCache {
    private LruCache mMemeryCache;

    public MemoryCache() {
        // 初始化LRU缓存
    }
    
    @Override
    public Bitmap get(String url) {
        return mMemeryCache.get(url);
    }

    @Override
    public void put(String url, Bitmap bmp) {
        mMemeryCache.put(url, bmp);
    }
}

// SD卡缓存DiskCache类
public class DiskCache implements ImageCache {
    @Override
    public Bitmap get(String url) {
        // 改为从本地文件获取图片
        return null;
    }

    @Override
    public void put(String url, Bitmap bmp) {
        // 将Bitmap写入文件中
    }
}

// 双缓存DoubleCache类
public class DoubleCache implements ImageCache {
    ImageCache mMemoryCache = new MemoryCache();
    ImageCache mDiskCache = new mDiskCache();

    // 先从内存中获取图片，如果没有再从SD卡中获取
    public Bitmap get(String url) {
        public Bitmap bitmap = mMemoryCache.get(url);
        if(bitmap == null) {
            bitmap = mDiskCache.get(url);
        }
        return bitmap;
    }

    // 将图片缓存到内存和SD卡中
    public void put(String url, Bitmap bmp) {
        mMemoryCache.put(url, bmp);
        mDiskCache.put(url, bmp);
    }
}

实现图片加载器类

public class ImageLoader {
    // 图片缓存，并设置了内存缓存为默认方式
    private ImageCache mImageCache = new MemoryCache();

    // 注入缓存实现  利用了向上转型
    public void setImageCache(ImageCache imageCache) {
        mImageCache = imageCache;
    }

    public void displayImage(String imageUrl, ImageView imageView) {
        Bitmap bitmap = mImageCache.get(imageUrl);
        if(bitmap != null) {
            imageView.setImageBitmap(bitmap);
            return;
        }
        // 图片没有缓存，提交到线程池中下载图片
        submitLoadRequest(imageUrl, imageView)
    }

    public void submitLoadRequest(final String imageUrl, final ImageView imageView) {
        // 下载图片
        // 缓存
        mImageCache.put(imageUrl, bitmap);
     }

    // 省略其他成员变量和方法
}

调用方法

//  使用方法  只是通过传入不同实现就可以切换缓存方式
ImageLoader loader = new ImageLoader();
loader.setImageCache(new MemoryCache());  // 使用内存缓存
loader.setImageCache(new DiskCache());  // 使用SD卡缓存
loader.setImageCache(new DoubleCache());  // 使用双缓存

// 使用自定义的图片缓存实现
loader.setImageCache(new ImageCache() {
    @Override
    public Bitmap get(String url) {
        // 改为从本地文件获取图片
        return null;
    }

    @Override
    public void put(String url, Bitmap bmp) {
        // 将Bitmap写入文件中
    }
    });

我们看得到通过setImageCache(ImageCache imageCache) 方式注入不同的缓存实现，使得ImageLoader代码变得更简单，健壮，提升高了它的灵活性和可扩展性，如果还有还有新的缓存方式，只需要去实现ImageCachej接口就可以使用了。

所以当需求发生变化时，应该尽量通过扩展的方式来实现变化，而不是通过修改已有代码来实现，但要做到开闭原则，首先我们应该先写出更易扩展的代码。

里氏替换原则

里氏替换原则英文全称是Liskov Substitution Principle，缩写是LSP。LSP的第一种定义是：如果对每一个类型为S的对象O1，都有类型为T的对象O2，使得以T定义的所有程序P在所有的对象O1都代换成O2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。
或者说是：所有引用基类的地方必须能透明地使用其子类的对象。

就像开闭原则中举的例子，创建了一个ImageCache，而其他缓存类都是他的实现类，而setImageCache(ImageCache imageCache) 需要的就是ImageCache类型，这时候我们就可以使用MemoryCache，DiskCache，DoubleCache来替换ImageCache的工作。ImageCache确定了规范，而新的缓存需求都可以通过实现它然后替换ImageCache来工作，从而保证了可扩展性。

也可以看一下系统代码

// 窗口类
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() {
        // 绘制文本
    }
}

故里氏替换原则就是通过建立抽象，建立规范，然后在运行时通过具体实现来替换掉抽象，从而保证了系统的扩展性和灵活性。可见，在开发过程中运用抽象是走向代码优化的重要一步。

开闭原则和里氏替换原则往往都是一同出现的，通过里氏替换原则达到对扩展的开发，对修改关闭的效果。

依赖倒置原则

依赖倒置原则英文全称是Dependence Inversion Principle，缩写是DIP。依赖倒置原则指代了一种特定的解耦形式，使得高层次的模块不依赖于低层次的模块的实现细节的目的，依赖模块被颠倒了。

依赖倒置原则的三个关键点：

1. 高层次模块不应该依赖于底层模块，两者都应该依赖其抽象。
2. 抽象不应依赖细节。
3. 细节应该依赖抽象。

抽象就是指接口或者抽象类；细节就是实现类；高层模块就是调用端，低层模块就是具体实现类。

依赖倒置原则在Java中表现就是：模块间依赖是通过抽象发生的，实现类之间并不产生直接依赖关系，其依赖关系是通过接口或抽象类产生的。
一句话概括：面向接口编程，或者说面向抽象编程。

我们依然可以通过上面的例子继续说明，代码如下：

//  如果在ImageLoader中直接这样写的话
//  就是直接依赖于细节(直接依赖实现类)
private DoubleCache mCache = new DoubleCache();
public void setImageCache(DoublieCache cache) {
    mCache = cache;
}

而我们的代码却直接完成1.2.3.4这四个原则

//  依赖于抽象，通过向上转型，有一个默认的实现类
private ImageCache mImageCache = new MemoryCache();

//  设置缓存策略，依赖于抽象
public void setImageCache(ImageCache imageCache) {
    mImageCache = imageCache;
}

依赖于抽象，依赖于基类，这样当需求发生变化，只需要实现ImageCache或者继承已实现的之类都可以完成缓存功能，然后将实现注入到setImageCache(ImageCache imageCache)就可以了。

接口隔离原则

接口隔离原则英文全称是InterfaceSegregation Principles，缩写是ISP。ISP的定义是：客户端不应该依赖它不需要的接口。或者说类的依赖关系应该将在最小的接口上。

接口隔离的目的是系统接口耦合，从而容易重构、更改和重新部署。一句话：让客户端依赖的接口尽可能小。

举一个例子，当我们在使用流的时候我们需要在finally中判断是否为空，如果不为空需要close()它，但每次使用流，都这么写，也会让代码变得不优美，这个时候我们考虑借助外力，就比如Java为我们提供了一个Closeable接口，而它有100多个实现类，所以那些类都可以使用它，代码如下：

//  这就是修改之前的代码 try/catch中还有try/catch
FileOutputStream fileOutputStream = null;
try {
//  逻辑省略
} catch (Exception e) {
        e.printStackTrace();
} finally {
        if (fileOutputStream != null) {
                try {
                        fileOutputStream.close();
               } catch (IOException e) {
                        e.printStackTrace();
               }
        }
}

//  写了个CloseUtil类，然后西面提供这个静态方法，所有实现了Closeable的类都可以调用这个方法
 public static void closeQuietly (Closeable closeable) {
        if (closeable != null) {
            try {
                closeable.close();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
}

//  我们只需要在finally中调用这一句话就好了
CloseUtil.closeQuietly(xxx);

不仅让代码的可读性增加了，还保证了它的重用性，这里也用到了依赖倒置原则，closeQuietly()方法的参数就一个抽象，做到了我只需要知道这个对象是可关闭的，其他一概不管辛，也就是作者所说的接口隔离原则。

迪米特原则

迪米特原则英文全称为Law of Demeter，缩写是LOD，也称为最少知识原则（Least Knowledge Principle）。LOD的定义是：一个对象应该对其他对象有最少的了解。

通俗的讲，一个类应该对自己需要耦合或者调用的类知道的最少，类的内部如何实现与调用者或者依赖者没有关系，只需要知道它需要的方法即可，其他的一概不管，类与类之间的关系越密切，耦合度也就越大。

迪米特原则还有一个英文解释：Only talk to your immediate friends.翻译过来也就是说之与直接朋友进行通信。

还是前面的ImageLoder，缓存这块是已经搞定了。假如在某次加载图片中,，缓存没找到就需要联网去服务器拿图片，并且需要存到缓存中以备下次直接从缓存加载，ok，很快可以写出这样的代码：

public class ImageLoder {
    private ImageCache mImageCache = new DoubleCache();
    //...
    public void dispalyImage(String url, ImageView imageView) {
        Bitmap bitmap = mImageCache.get(url);
        if (bitmap != null) {
            imageView.setImageBitmap(bitmap);
            return;
        }
        HttpImage4Service.down4Service(url, imageView, mImageCache);
    }
}

HttpImage4Service下载类中从网络中加载图片方法：

public static void down4Service(String url, ImageView imageView, ImageCache imageCache) {
        //...从网络拉取图片
        //回调↓
        imageView.setImageBitmap(bitmap4Service);//显示图片
        imageCache.put(url, bitmap4Service);//存到缓存中
    }

分析下这样设计的耦合情况,

• ImageLoder调用ImageCache和HttpImage4Service。
• HttpImage4Service调用ImageCache。

三个类之间是否知道的最少？试想一下，从网络拉取图片跟缓存这样两个类应该有关联吗？实际上是没必要的，根据最少知识原则，改进之后应该是下面这样的：

public class ImageLoder {
    private ImageCache mImageCache = new DoubleCache();
    //...
    public void dispalyImage(String url, ImageView imageView) {
        Bitmap bitmap = mImageCache.get(url);
        if (bitmap != null) {
            imageView.setImageBitmap(bitmap);
            return;
        }
        bitmap=HttpImage4Service.down4Service(url);//只负责下载图片
        imageView.setImageBitmap(bitmap);
        imageCache.put(url, bitmap);//存到缓存中
    }
}

改进后三个类中只有ImageLoder调用HttpImage4Service和ImageCache中的方法，其余没有任何调用关系，耦合度降低。

在MVP中，View层和Model层拒绝通信，也是符合最少知识原则的，达到降低耦合效果，同时可扩展性会大大增加。

总结

应用开发，最难的不是完成开发工作，而是维护和升级。为了后续能够很好的维护和升级，我们的系统需要在满足稳定性的前提下保持以下三个特性：

• 高可扩展性
• 高内聚
• 低耦合

更多内容戳这里（整理好的各种文集）