Android设计模式的六大原则
转载仅供本人存档及后续研究使用，请尊重原创。
转载自：https://blog.csdn.net/weiyj2015/article/details/82660202
1、单一职责原则
单一职责原则的英文名称是Single Responsibility Principle，简称SRP。定义：就一个类而言，应该仅有一个引起它变化的原因。简单来说，一个类中应该是一组相关性很高的函数、数据的封装。
举个栗子：
ImageLoader（图片加载），功能需求：实现图片加载，并且要将图片缓存起来。
原本我们可能会写成：
/**
* 图片加载类
*/
public class ImageLoader {
// 图片缓存
LruCache mImageCache;
// 线程池,线程数量为CPU的数量
ExecutorService mExecutorService = Executors.newFixedThreadPool (Runtime.getRuntime().availableProcessors());
public ImageLoader() {
initImageCache();
}
private void initImageCache() {
// 计算可使用的最大内存
final int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
// 取四分之一的可用内存作为缓存
final int cacheSize = maxMemory / 4;
mImageCache = new LruCache(cacheSize) {
@Override
protected int sizeOf(String key, Bitmap bitmap) {
return bitmap.getRowBytes() * bitmap.getHeight() / 1024;
}
};
}
public void displayImage(final String url, final ImageView imageView) {
imageView.setTag(url);
mExecutorService.submit(new Runnable() {
@Override
public void run() {
Bitmap bitmap = downloadImage(url);
if (bitmap == null) {
return;
}
if (imageView.getTag().equals(url)) {
imageView.setImageBitmap(bitmap);
}
mImageCache.put(url, bitmap);
}
});
}
public Bitmap downloadImage(String imageUrl) {
Bitmap bitmap = null;
try {
URL url = newURL(imageUrl);
final HttpURLConnection conn =
(HttpURLConnection)url.openConnection();
bitmap = BitmapFactory.decodeStream(
conn.getInputStream());
conn.disconnect();
} catch (Exception e) {
e.printStackTrace();
}
return bitmap;
}
} 但是这样耦合太严重，所有的功能都写在一个类里，随着功能的增多，ImageLoader类会越来越大，代码也越来越复杂，图片加载系统就越来越脆弱。
下面根据单一职责原则，修改代码如下：
ImageLoader类：
/**
* 图片加载类
*/
public class ImageLoader {
// 图片缓存
ImageCache mImageCache = new ImageCache() ;
// 线程池,线程数量为CPU的数量
ExecutorService mExecutorService = Executors.newFixedThreadPool (Runtime.getRuntime().availableProcessors());
// 加载图片
public void displayImage(final String url, final ImageView imageView) {
Bitmap bitmap = mImageCache.get(url);
if (bitmap != null) {
imageView.setImageBitmap(bitmap);
return;
}
imageView.setTag(url);
mExecutorService.submit(new Runnable() {
@Override
public void run() {
Bitmap bitmap = downloadImage(url);
if (bitmap == null) {
return;
}
if (imageView.getTag().equals(url)) {
imageView.setImageBitmap(bitmap);
}
mImageCache.put(url, bitmap);
}
});
}
public Bitmap downloadImage(String imageUrl) {
Bitmap bitmap = null;
try {
URL url = new URL(imageUrl);
final HttpURLConnection conn =
(HttpURLConnection)
url.openConnection();
bitmap = BitmapFactory.decodeStream(conn.getInputStream());
conn.disconnect();
} catch (Exception e) {
e.printStackTrace();
}
return bitmap;
}
} 并且添加了一个ImageCache类用于处理图片缓存，具体代码如下：
public class ImageCache {
// 图片LRU缓存
LruCache mImageCache;
public ImageCache() {
initImageCache();
}
private void initImageCache() {
// 计算可使用的最大内存
final int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
// 取四分之一的可用内存作为缓存
final int cacheSize = maxMemory / 4;
mImageCache = new LruCache(cacheSize) {
@Override
protected int sizeOf(String key, Bitmap bitmap) {
return bitmap.getRowBytes() *
bitmap.getHeight() / 1024;
}
};
}
public void put(String url, Bitmap bitmap) {
mImageCache.put(url, bitmap) ;
}
public Bitmap get(String url) {
return mImageCache.get(url) ;
}
} 将ImageLoader一拆为二，ImageLoader只负责图片加载的逻辑，而ImageCache只负责处理图片缓存的逻辑，这样ImageLoader的代码量变少了，职责也清晰了，当与缓存相关的逻辑需要改变时，不需要修改ImageLoader类，而图片加载的逻辑需要修改时也不会影响到缓存处理逻辑。虽然可扩展性比较欠缺，后面我们再继续优化。
单一职责原则优点:
类的复杂性降低，实现什么职责都有清晰明确的定义。
可读性提高，复杂性降低，那当然可读性提高了。
可维护性提高，可读性提高，那当然更容易维护了。
变更引起的风险降低，变更是必不可少的，如果接口的单子职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口的变更无影响，这是系统的扩展性、维护性都有非常大的帮助。
2、开闭原则
开闭原则的英文全称是Open Close Principle，简称OCP。定义：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是，对于修改是封闭的。在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会将错误引入原本已经经过测试的旧代码中，破坏原有系统。因此，当软件需要变化时，我们应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。当然，在现实开发中，只通过继承的方式来升级、维护原有系统只是一个理想化的愿景，因此，在实际的开发过程中，修改原有代码、扩展代码往往是同时存在的。
继续使用上面的例子，在上面例子的基础上，现在新增需求：需要sd卡缓存图片。
我们可能会这样做：
DiskCache.java类，将图片缓存到SD卡中：
public class DiskCache {
// 为了简单起见临时写个路径,在开发中请避免这种写法 !
static String cacheDir = "sdcard/cache/";
// 从缓存中获取图片
public Bitmap get(String url) {
return BitmapFactory.decodeFile(cacheDir + url);
}
// 将图片缓存到内存中
public void put(String url, Bitmap bmp) {
FileOutputStream fileOutputStream = null;
try {
fileOutputStream = new
FileOutputStream(cacheDir + url);
bmp.compress(CompressFormat.PNG,
100, fileOutputStream);
} catch (FileNotFoundException e) {
e.printStackTrace();
} final ly {
if (fileOutputStream != null) {
try {
fileOutputStream.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
}
}因为需要将图片缓存到SD卡中，所以，ImageLoader代码有所更新，具体代码如下：
public class ImageLoader {
// 内存缓存
ImageCache mImageCache = new ImageCache();
// SD卡缓存
DiskCache mDiskCache = new DiskCache();
// 是否使用SD卡缓存
boolean isUseDiskCache = false;
// 线程池,线程数量为CPU的数量
ExecutorService mExecutorService = Executors.newFixedThreadPool (Runtime.getRuntime().availableProcessors());
public void displayImage(final String url, final ImageView imageView) {
// 判断使用哪种缓存
Bitmap bitmap = isUseDiskCache ? mDiskCache.get(url)
: mImageCache.get (url);
if (bitmap != null) {
imageView.setImageBitmap(bitmap);
return;
}
// 没有缓存，则提交给线程池进行下载
}
public void useDiskCache(boolean useDiskCache) {
isUseDiskCache = useDiskCache ;
}
}从上述的代码中可以看到，仅仅新增了一个DiskCache类和往ImageLoader类中加入了少量代码就添加了SD卡缓存的功能，可以通过useDiskCache方法来对使用哪种缓存进行设置，例如：
ImageLoader imageLoader = new ImageLoader() ;
// 使用SD卡缓存
imageLoader.useDiskCache(true);
// 使用内存缓存
imageLoader.useDiskCache(false);虽然上面的代码通过useDiskCache方法可以设置不同的缓存，但是有些明显的问题，就是使用内存缓存时就不能使用SD卡缓存，类似的，使用SD卡缓存时就不能使用内存缓存。如果需要这两种策略的综合，即首先缓存优先使用内存缓存，如果内存缓存没有图片再使用SD卡缓存，如果SD卡中也没有图片最后才从网络上获取，这才是最好的缓存策略。
于是继续修改，新建一个双缓存类DoudleCache，具体代码如下：
/**
* 双缓存。获取图片时先从内存缓存中获取，如果内存中没有缓存该图片，再从SD卡中获取。
* 缓存图片也是在内存和SD卡中都缓存一份
*/
public class DoubleCache {
ImageCache mMemoryCache = new ImageCache();
DiskCache mDiskCache = new DiskCache();
// 先从内存缓存中获取图片，如果没有，再从SD卡中获取
public Bitmap get(String url) {
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);
}
}修改ImageLoader类
public class ImageLoader {
// 内存缓存
ImageCache mImageCache = new ImageCache();
// SD卡缓存
DiskCache mDiskCache = new DiskCache();
// 双缓存
DoubleCache mDoubleCache = new DoubleCache() ;
// 使用SD卡缓存
boolean isUseDiskCache = false;
// 使用双缓存
boolean isUseDoubleCache = false;
// 线程池,线程数量为CPU的数量
ExecutorService mExecutorService = Executors.newFixedThreadPool (Runtime.getRuntime().availableProcessors());
public void displayImage(final String url, final ImageView imageView) {
Bitmap bmp = null;
if (isUseDoubleCache) {
bmp = mDoubleCache.get(url);
} else if (isUseDiskCache) {
bmp = mDiskCache.get(url);
} else {
bmp = mImageCache.get(url);
}
if ( bmp != null ) {
imageView.setImageBitmap(bmp);
}
// 没有缓存，则提交给线程池进行异步下载图片
}
public void useDiskCache(boolean useDiskCache) {
isUseDiskCache = useDiskCache ;
}
public void useDoubleCache(boolean useDoubleCache) {
isUseDoubleCache = useDoubleCache ;
}
}分析一下上面的代码，每次在程序中加入新的缓存实现时都需要修改ImageLoader类，然后通过一个布尔变量来区分使用哪种缓存，因此，就使得在ImageLoader中存在各种if-else判断，通过这些判断来确定使用哪种缓存。随着这些逻辑的引入，代码变得越来越复杂、脆弱，如果一不小心写错了某个if条件（条件太多，这是很容易出现的），那就需要更多的时间来排除。整个ImageLoader类也会变得越来越臃肿。最重要的是不能实现缓存注入到ImageLoader中，可扩展性可是框架的最重要特性之一。
软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是对于修改是封闭的，这就是开放-关闭原则。也就是说，当软件需要变化时，我们应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。
下面我们根据开闭原则来重构下上面的代码：
ImageLoader类:
public class ImageLoader {
// 图片缓存
ImageCache mImageCache = new MemoryCache();
// 线程池,线程数量为CPU的数量
ExecutorService mExecutorService = Executors.newFixedThreadPool (Runtime.getRuntime().availableProcessors());
// 注入缓存实现
public void setImageCache(ImageCache cache) {
mImageCache = cache;
}
public void displayImage(String imageUrl, ImageView imageView) {
Bitmap bitmap = mImageCache.get(imageUrl);
if (bitmap != null) {
imageView.setImageBitmap(bitmap);
return;
}
// 图片没缓存，提交到线程池中下载图片
submitLoadRequest(imageUrl, imageView);
}
private void submitLoadRequest(final String imageUrl,
final ImageView imageView) {
imageView.setTag(imageUrl);
mExecutorService.submit(new Runnable() {
@Override
public void run() {
Bitmap bitmap = downloadImage(imageUrl);
if (bitmap == null) {
return;
}
if (imageView.getTag().equals(imageUrl)) {
imageView.setImageBitmap(bitmap);
}
mImageCache.put(imageUrl, bitmap);
}
});
}
public Bitmap downloadImage(String imageUrl) {
Bitmap bitmap = null;
try {
URL url = new URL(imageUrl);
final HttpURLConnection conn = (HttpURLConnection)
url.openConnection();
bitmap = BitmapFactory.decodeStream(conn.getInputStream());
conn.disconnect();
} catch (Exception e) {
e.printStackTrace();
}
return bitmap;
}
}经过这次重构，没有了那么多的if-else语句，没有了各种各样的缓存实现对象、布尔变量。
新增ImageCache接口
public interface ImageCache {
public Bitmap get(String url);
public void put(String url, Bitmap bmp);
}ImageCache接口简单定义了获取、缓存图片两个函数，缓存的key是图片的url，值是图片本身。内存缓存、SD卡缓存、双缓存都实现了该接口，我们看看这几个缓存实现类：
// 内存缓存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 DiskCache();
// 先从内存缓存中获取图片，如果没有，再从SD卡中获取
public Bitmap get(String url) {
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);
}
} ImageLoader类中增加了一个setImageCache（ImageCache cache）函数，可以通过该函数设置缓存实现，也就是通常说的依赖注入。下面就看看是如何设置缓存实现的：
ImageLoader imageLoader = new ImageLoader() ;
// 使用内存缓存
imageLoader.setImageCache(new MemoryCache());
// 使用SD卡缓存
imageLoader.setImageCache(new DiskCache());
// 使用双缓存
imageLoader.setImageCache(new DoubleCache());
// 使用自定义的图片缓存实现
imageLoader.setImageCache(new ImageCache() {
@Override
public void put(String url, Bitmap bmp) {
// 缓存图片
}
@Override
public Bitmap get(String url) {
return null/*从缓存中获取图片*/;
}
});在上述代码中，通过setImageCache（ImageCache cache）方法注入不同的缓存实现，这样不仅能够使ImageLoader更简单、健壮，也使得ImageLoader的可扩展性、灵活性更高。MemoryCache、DiskCache、DoubleCache缓存图片的具体实现完全不一样，但是，它们的一个特点是都实现了ImageCache接口。当用户需要自定义实现缓存策略时，只需要新建一个实现ImageCache接口的类，然后构造该类的对象，并且通过setImageCache（ImageCache cache）注入到ImageLoader中，这样ImageLoader就实现了变化万千的缓存策略，而扩展这些缓存策略并不会导致ImageLoader类的修改。
开闭原则优点:
增加稳定性。
可扩展性高。
3、里氏替换原则
里氏替换原则英文全称是Liskov Substitution Principle，简称LSP。定义：所有引用基类的地方必须能透明地使用其子类的对象。通俗点讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。
举个例子，Android中的Window与View的关系
// 窗口类
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(){
// 绘制文本
}
}上述示例中，Window依赖于View，而View定义了一个视图抽象，measure是各个子类共享的方法，子类通过覆写View的draw方法实现具有各自特色的功能，在这里，这个功能就是绘制自身的内容。任何继承自View类的子类都可以设置给show方法，也就我们所说的里氏替换。通过里氏替换，就可以自定义各式各样、千变万化的View，然后传递给Window，Window负责组织View，并且将View显示到屏幕上。
里氏替换原则的核心原理是抽象，抽象又依赖于继承这个特性，在OOP当中，继承的优缺点都相当明显。
优点如下：
代码重用，减少创建类的成本，每个子类都拥有父类的方法和属性；
子类与父类基本相似，但又与父类有所区别；
提高代码的可扩展性。
继承的缺点：
继承是侵入性的，只要继承就必须拥有父类的所有属性和方法；
可能造成子类代码冗余、灵活性降低，因为子类必须拥有父类的属性和方法。
事物总是具有两面性，如何权衡利与弊都是需要根据具体场景来做出选择并加以处理。里氏替换原则指导我们构建扩展性更好的软件系统，我们还是接着上面的ImageLoader来做说明。
上面ImageLoader例子中的MemoryCache、DiskCache、DoubleCache都可以替换ImageCache的工作，并且能够保证行为的正确性。ImageCache建立了获取缓存图片、保存缓存图片的接口规范，MemoryCache等根据接口规范实现了相应的功能，只需要在使用时指定具体的缓存对象就可以动态地替换ImageLoader中的缓存策略。这就使得ImageLoader的缓存系统具有了无线的可能性，也就是保证了可扩展性。
里氏替换原则优点:
代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性。
提高代码的重用性。
提高代码的可扩展性，实现父类的方法就可以“为所欲为”了，很多开源框架的扩展接口都是通过继承父类来完成的。
提高产品或项目的开放性。
里氏替换原则缺点:
继承是侵入性的。只要继承，就必须拥有父类的所有属性和方法。
降低代码的灵活性。子类必须拥有父类的属性和方法，让子类自由的世界中多了些约束。
增强了耦合性。当父类的常量、变量和方法被修改时，必须要考虑子类的修改，而且在缺乏规范的环境下，这种修改可能带来非常糟糕的结果——大片的代码需要重构。
4、依赖倒置原则
依赖倒置原则英文全称是Dependence Inversion Principle，简称DIP。依赖反转原则指代了一种特定的解耦形式，使得高层次的模块不依赖于低层次的模块的实现细节的目的，依赖模块被颠倒了。
依赖倒置原则的几个关键点：
高层模块不应该依赖低层模块，两者都应该依赖其抽象；
抽象不应该依赖细节；
细节应该依赖抽象。
在Java语言中，先解释下几个关键字：
抽象--就是指接口或抽象类，两者都是不能直接被实例化的；
细节--就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是，可以直接被实例化，也就是可以加上一个关键字 new 产生一个对象；
高层模块--就是调用端；
低层模块--就是具体实现类；
依赖倒置原则在 Java 语言中的表现就是：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。这又是一个将理论抽象化的实例，其实一句话就可以概括：面向接口编程，或者说是面向抽象编程，这里的抽象指的是接口或者抽象类。面向接口编程是面向对象精髓之一，也就是上面两节强调的抽象。
如果在类与类直接依赖于细节，那么它们之间就有直接的耦合，当具体实现需要变化时，意味着在这要同时修改依赖者的代码，并且限制了系统的可扩展性。在ImageLoader例子中，ImageLoader直接依赖于MemoryCache，这个MemoryCache是一个具体实现，而不是一个抽象类或者接口。这导致了ImageLoader直接依赖了具体细节，当MemoryCache不能满足ImageLoader而需要被其他缓存实现替换时，此时就必须修改ImageLoader的代码，例如：
public class ImageLoader {
// 内存缓存 ( 直接依赖于细节 )
MemoryCache mMemoryCache = new MemoryCache();
// 加载图片到ImageView中
public void displayImage(String url, ImageView imageView) {
Bitmap bmp = mMemoryCache.get(url);
if (bmp == null) {
downloadImage(url, imageView);
} else {
imageView.setImageBitmap(bmp);
}
}
public void setImageCache(MemoryCache cache) {
mCache = cache ;
}
// 代码省略
}我们依旧拿ImageLoader举例：
此时需求变更为ImageLoader可以将图片同时缓存到内存和SD卡中，或者可以让用户自定义实现缓存。
此时，我们的MemoryCache这个类名不仅不能够表达内存缓存和SD卡缓存的意义，也不能够满足功能。
ImageLoader修改如下：
public class ImageLoader {
// 双缓存 ( 直接依赖于细节 )
DoubleCache mCache = new DoubleCache();
// 加载图片到ImageView中
public void displayImage(String url, ImageView imageView) {
Bitmap bmp = mCache.get(url);
if (bmp == null) {
// 异步下载图片
downloadImageAsync(url, imageView);
} else {
imageView.setImageBitmap(bmp);
}
}
public void setImageCache(DoubleCache cache) {
mCache = cache ;
}
// 代码省略
}我们将MemoryCache修改成DoubleCache，然后修改了ImageLoader中缓存类的具体实现，轻轻松松就满足了功能需求。等等！这不还是依赖于具体的实现类（DoubleCache）吗？当用功能需求再次变化时，我们又要通过修改缓存实现类和ImageLoader代码来实现？修改原有代码不是违反了开闭原则吗？
依赖抽象，而不依赖具体实现。针对于图片缓存，主管建立的ImageCache抽象，该抽象中增加了get和put方法用以实现图片的存取。每种缓存实现都必须实现这个接口，并且实现自己的存取方法。当需要使用不同的缓存实现时，直接通过依赖注入即可，保证了系统的灵活性。我们再来简单回顾一下相关代码：
ImageCache缓存抽象：
public interface ImageCache {
public Bitmap get(String url);
public void put(String url, Bitmap bmp);
}ImageLoader类：
public class ImageLoader {
// 图片缓存类，依赖于抽象，并且有一个默认的实现
ImageCache mCache = new MemoryCache();
// 加载图片
public void displayImage(String url, ImageView imageView) {
Bitmap bmp = mCache.get(url);
if (bmp == null) {
// 异步加载图片
downloadImageAsync(url, imageView);
} else {
imageView.setImageBitmap(bmp);
}
}
/**
* 设置缓存策略,依赖于抽象
*/
public void setImageCache(ImageCache cache) {
mCache = cache;
}
// 代码省略
}在这里，我们建立了ImageCache抽象，并且让ImageLoader依赖于抽象而不是具体细节。当需求发生变更时，只需要实现ImageCahce类或者继承其他已有的ImageCache子类完成相应的缓存功能，然后将具体的实现注入到ImageLoader即可实现缓存功能的替换，这就保证了缓存系统的高可扩展性，拥有了拥抱变化的能力，而这一切的基本指导原则就是我们的依赖倒置原则。从上述几节中我们发现，要想让我们的系统更为灵活，抽象似乎成了我们唯一的手段。
依赖倒置原则优点:
可扩展性好。
耦合度低。
5、接口隔离原则
接口隔离原则英文全称是InterfaceSegregation Principles，简称ISP。它的定义是：客户端不应该依赖它不需要的接口。
举个例子：
在Java 6以及之前的JDK版本，有一个非常讨厌的问题，那就是在使用了OutputStream或者其他可关闭的对象之后，我们必须保证它们最终被关闭了，我们的SD卡缓存类中就有这样的代码：
// 将图片缓存到内存中
public void put(String url, Bitmap bmp) {
FileOutputStream fileOutputStream = null;
try {
fileOutputStream = new FileOutputStream(cacheDir + url);
bmp.compress(CompressFormat.PNG, 100, fileOutputStream);
} catch (FileNotFoundException e) {
e.printStackTrace();
} finally {
if (fileOutputStream != null) {
try {
fileOutputStream.close();
} catch (IOException e) {
e.printStackTrace();
}
} // end if
} // end if finally
}我们看到的这段代码可读性非常差，各种try…catch嵌套，都是些简单的代码，但是会严重影响代码的可读性，并且多层级的大括号很容易将代码写到错误的层级中。大家应该对这类代码也非常反感，那我们看看如何解决这类问题。
我们可能知道Java中有一个Closeable接口，该接口标识了一个可关闭的对象，它只有一个close方法。
我们要讲的FileOutputStream类就实现了这个接口，此外还有一百多个类实现了Closeable这个接口，这意味着，在关闭这一百多个类型的对象时，都需要写出像put方法中finally代码段那样的代码。我们可以建一个方法统一来关闭这些对象。
public final class CloseUtils {
Private CloseUtils() { }
/**
* 关闭Closeable对象
* @param closeable
*/
public static void closeQuietly(Closeable closeable) {
if (null != closeable) {
try {
closeable.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
}我们再看看把这段代码运用到上述的put方法中的效果如何：
public void put(String url, Bitmap bmp) {
FileOutputStream fileOutputStream = null;
try {
fileOutputStream = new FileOutputStream(cacheDir + url);
bmp.compress(CompressFormat.PNG, 100, fileOutputStream);
} catch (FileNotFoundException e) {
e.printStackTrace();
} final ly {
CloseUtils.closeQuietly(fileOutputStream);
}
}代码简洁了很多！而且这个closeQuietly方法可以运用到各类可关闭的对象中，保证了代码的重用性。CloseUtils的closeQuietly方法的基本原理就是依赖于Closeable抽象而不是具体实现（这不是依赖倒置原则么），并且建立在最小化依赖原则的基础，它只需要知道这个对象是可关闭，其他的一概不关心，也就是这里的接口隔离原则。
接口隔离原则优点:
降低耦合性。
提高代码可读性。
隐藏实现细节。
6、迪米特原则
迪米特原则英文全称为Law of Demeter，简称LOD，也称为最少知识原则（Least Knowledge Principle）。虽然名字不同，但描述的是同一个原则：一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，类的内部如何实现、如何复杂都与调用者或者依赖者没关系，调用者或者依赖者只需要知道他需要的方法即可，其他的我一概不关心。类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
举个栗子：
我们设定的情境为：我只要求房间的面积和租金，其他的一概不管，中介将符合我要求的房子提供给我就可以。下面我们看看这个示例：
/**
* 房间
*/
public class Room {
public float area;
public float price;
public Room(float area, float price) {
this.area = area;
this.price = price;
}
@Override
public String toString() {
return "Room [area=" + area + ", price=" + price + "]";
}
}
/**
* 中介
*/
public class Mediator {
List mRooms = new ArrayList();
public Mediator() {
for (inti = 0; i < 5; i++) {
mRooms.add(new Room(14 + i, (14 + i) * 150));
}
}
public ListgetAllRooms() {
return mRooms;
}
}
/**
* 租户
*/
public class Tenant {
public float roomArea;
public float roomPrice;
public static final float diffPrice = 100.0001f;
public static final float diffArea = 0.00001f;
public void rentRoom(Mediator mediator) {
Listrooms = mediator.getAllRooms();
for (Room room : rooms) {
if (isSuitable(room)) {
System.out.println("租到房间啦! " + room);
break;
}
}
}
private boolean isSuitable(Room room) {
return Math.abs(room.price - roomPrice) < diffPrice
&&Math.abs(room.area - roomArea) < diffArea;
}
} 从上面的代码中可以看到，Tenant不仅依赖了Mediator类，还需要频繁地与Room类打交道。租户类的要求只是通过中介找到一间适合自己的房间罢了，不需要关注Romm类的细节。导致耦合较高。
下面重构代码进行解耦：
/**
* 中介
*/
public class Mediator {
List mRooms = new ArrayList();
public Mediator() {
for (inti = 0; i < 5; i++) {
mRooms.add(new Room(14 + i, (14 + i) * 150));
}
}
public Room rentOut(float area, float price) {
for (Room room : mRooms) {
if (isSuitable(area, price, room)) {
return room;
}
}
return null;
}
private boolean isSuitable(float area, float price, Room room) {
return Math.abs(room.price - price) < Tenant.diffPrice
&& Math.abs(room.area - area) < Tenant.diffPrice;
}
}
/**
* 租户
*/
public class Tenant {
public float roomArea;
public float roomPrice;
public static final float diffPrice = 100.0001f;
public static final float diffArea = 0.00001f;
public void rentRoom(Mediator mediator) {
System.out.println("租到房啦 " + mediator.rentOut(roomArea, roomPrice));
}
} 只是将对于Room的判定操作移到了Mediator类中，这本应该是Mediator的职责，他们根据租户设定的条件查找符合要求的房子，并且将结果交给租户就可以了。租户并不需要知道太多关于Room的细节，比如与房东签合同、房东的房产证是不是真的、房内的设施坏了之后我要找谁维修等，这样看是不是代码耦合度更低、稳定性更好。
迪米特原则优点:
降低复杂度。
降低耦合性。
增加稳定性。
总结
在应用开发过程中，最难的不是完成应用的开发工作，而是在后续的升级、维护过程中让应用系统能够拥抱变化。拥抱变化也就意味着在满足需求且不破坏系统稳定性的前提下保持高可扩展性、高内聚、低耦合，在经历了各版本的变更之后依然保持清晰、灵活、稳定的系统架构。当然，这是一个比较理想的情况，但我们必须要朝着这个方向去努力，那么遵循面向对象六大原则就是我们走向灵活软件之路所迈出的第一步。
---------------------------------------------------------------------------------------------------------------------------
早计划，早准备，早完成。 欢迎关注！交流！Star！
GitHub：https://github.com/wangyang0313
微信公众号：一个灵活的胖子MrWang
简书：https://www.jianshu.com/u/e5e733d79b96
