设计模式-面向对象六大原则

面向对象六大原则

本文为读书笔记以及一个观后理解写下，有误望能指出

1、单一职责原则

简单理解就是在一个类中完成本类的职责而不要过多添加其他的职责，以一个反例的图片加载器来理解

public class ImageLoader{
	...
	//初始化缓存
	initImageCache(){...}
	//展示图片
	dispalyImage(){...}
	//下载图片
	downloadImage(){...}
}

ImageLoader中除了加载功能之外，还加入了一个对于缓存的操作，耦合度过大。所以可以进行解耦就是将Cache的功能提取出来，提供get、put方法给ImageLoader调用

public class ImageLoader{
        //具体的细节可忽略，本代码主要为了讲解几个函数功能
        ImageCache mCache = new ImageCache();
	...
	//展示图片
	dispalyImage(){
		mCache.get(url);
		...
	}
	//下载图片
	downloadImage(){...}
}

public class ImageCache(){
	//初始化缓存
	initImageCache(){...}
	put(){...}
	get(){...}
}

将功能分开，具体分到每个类当中，与上述的第一个例子区别就是职责分开了，当出现需要对ImageCache修改的时候，ImageLoader并不会影响到，ImageLoader无须关注ImageCache的细节。

2、开闭原则

定义就是对于扩展是开放的，而对于修改是封闭的。按字面理解就是尽量通过去继承子类或者接口的而不是去修改原有的类，除非类出现错误才会去修改原类。这样的目的是什么？好处之一就是为了一个稳定性，在一个庞大的代码系统修改一处代码可能造成未知的错误，所以通过继承原类去扩展可以保证稳定

上一个单一原则的例子中我们定义了ImageCache类默认为内存缓存，那么加入我们想要使用SD卡的缓存，此时我们就得去修改已有的函数代码，不安全也不稳定，那么我们在设计代码的时候，可以通过将ImageCache写成接口/抽象类，具体想要实现的有我们写的代码来实现

public interface ImageCache{
	Bitmap get();
	void put();
}

public class MemoryCache implements ImageCache{
	@Override
	Bitmap get(){...}
	...
}

public class ImageLoader{
    //具体的细节可忽略，本代码主要为了讲解几个函数功能
    ImageCache mCache = new MemoryCache();
	...
	//展示图片
	dispalyImage(){
		mCache.get(url);
		...
	}
	//下载图片
	downloadImage(){...}
}

可以看到我们需要不同的Cache时，只需要实现接口即可快速扩展功能而不用在原有类去修改

3、里氏替换原则

这个原则跟第二个原则有些关系，里氏替换原则的原理是核心抽象，强调一个快速替换上述的第二原则中可以快速替换ImageCache为Memory或者SDCache，而第二个原则主要强调开闭的关系

4、依赖倒置原则

听起来有点抽象，我个人的理解就是一个类调用另一个类去实现功能是，不要通过直接的调用，比如我们上面的ImageCache，如果不是写成接口而是一个普通了，那么就是直接调用，ImageCache为具体细节实现，ImageLoader为调用类，类与类之间通过抽象类或者接口来实现依赖。说这么多有点抽象，还是通过例子好理解点。

public class ImageLoader{
	ImageCache mCache = new MemoryCache();
	...
	void setImageCache(ImageCache mCache){
		this.mCache = mCache;
	}
	...
}

我们默认将MemoryCache当成ImageCache，当需要改动时，通过setImageCache来改变Cache,通过抽象来依赖

5、接口隔离原则

这个原则对于个人不知道理解是否正确，我的理解就是将一些类拆分成粒度更小的类，比如我们常用的FileOutputStream，我们试用完之后需要close，其实FileOutputStream实现了Closeable接口，很多类都实现了这一个接口，那么我们就可以将其拆分出来，写成工具类CloseUtils(Closeable closeable)统一关闭接口，需要用是调用这个工具类就可以。

以上五个原则英文第一个字幕刚好可以组成SOLID原则

6、迪米特原则

终于来到这一节的最后一个原则了，这个原则的理解：只与直接的朋友通讯，通俗来讲一个类只需知道自己需要使用的功能即可，不需要知道具体的实现细节。举个栗子，我们租房通过中介，中介又去找屋主匹配。这个情况最直接了明，我们只需要知道想要什么房子，报给中介，具体房子怎样，合不合法（正规中介）即可，其他的细节由中介去理清楚，个人觉得更像是MVP模式。

我们继续拿上面的图片加载器来举例子，我们实现中有个缓存器，到底是内存缓存还是SD缓存不用考虑，ImageLoader是“我们”，抽象ImageCache是“中介”，具体Memory或者SD怎么实现我们并不需要去考虑，只需要具体“中介”去决定即可。

以上就是我们设计模式遵守的共同原则，无论使用什么模式都是遵从这些原则。我们可以发现其中用到最多的是一个抽象的使用，使得类与类之间耦合度降低，本人也是刚刚开始了解设计模式，欢迎大家一起分享交流。下一节从单例讲起