面向对象六大原则和23种设计模式，是开发人员不得不去认真学习的。《Android源码设计模式解析与实战》这本书对设计模式做了详细的介绍，本篇来源于这本书，如有不妥，还望见谅。
- 单一职责原则
- 开闭原则
- 里氏替换原则
- 依赖倒置原则
- 接口隔离原则
- 迪米特原则（最少知识原则）
单一职则原则
单一职责原则的英文名称是Single Responsibility Principle，缩写是SRP。SRP的定义是：就一个类而言，应该仅有一个引发它变化的原因。简单来说，一个类中应该是一组相关性很高的函数、数据的封装。
以图片加载器（ImageLoader）项目为例，要求：实现图片加载，并且要将图片缓存起来。
public class ImageLoader {
// 图片缓存
LruCache<String, Bitmap> mImageCache;
// 线程池，线程数量为CPU的数量
ExecutorService mExecutorService = Executors.newFixedThreadPool(
Runtime.getRuntime().availableProcessors());
public ImageLoader(){
initImageCache();
}
/**
* 初始化图片的缓存
*/
private void initImageCache(){
// 计算可用的最大内存(千字节kb)，
// Runtime.getRuntime().maxMemory()返回尝试使用的最大内存量，以字节为单位。
int maxMemory = (int) (Runtime.getRuntime().maxMemory()/1024);
// 取1/4的可用内存作为缓存
int cacheSize = maxMemory/4;
mImageCache = new LruCache<String, Bitmap>(cacheSize){
// 每一项的大小
@Override
protected int sizeOf(String key, Bitmap bitmap) {
// Bitmap所占用的内存空间数等于Bitmap的每一行所占用的空间数乘以Bitmap的行数
// 即bitmap的行字节*高度
return bitmap.getRowBytes()*bitmap.getHeight()/1024;
}
};
}
/**
* 在ImageView中显示图片
*/
public void displayImage(final String url, final ImageView imageView){
imageView.setTag(url);
mExecutorService.execute(new Runnable() {
@Override
public void run() {
Bitmap bitmap = downImage(url);
if (bitmap == null) {
return;
}
if (imageView.getTag().equals(url)) {
imageView.setImageBitmap(bitmap);
}
mImageCache.put(url, bitmap);
}
});
}
/**
* 根据url下载图片
*/
public Bitmap downImage(String imageUrl) {
Bitmap bitmap = null;
try {
URL url = new URL(imageUrl);
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
bitmap = BitmapFactory.decodeStream(conn.getInputStream());
conn.disconnect();
} catch (Exception e) {
e.printStackTrace();
}
return bitmap;
}
}
上面的代码出现了严重的问题：耦合严重，简直没有设计可言，更不要说扩展性、灵活性了。所有的功能写在一个类中，以后随着功能的增多，ImageLoader类会越来越大，代码也越来越复杂，图片加载系统就越来越脆弱。
分析问题：将ImageLoader拆分，把各个功能独立出来，让它们满足单一职责原则。
解决问题：画UML类图，根据类图重构代码。 
public class ImageLoader {
// 图片缓存
ImageCache mImageCache = new ImageCache();
// 线程池，线程数量为CPU的数量
ExecutorService mExecutorService = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());
/**
* 在ImageView中显示图片
*/
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.execute(new Runnable() {
@Override
public void run() {
Bitmap bitmap = downImage(url);
if (bitmap == null) {
return;
}
if (imageView.getTag().equals(url)) {
imageView.setImageBitmap(bitmap);
}
mImageCache.put(url, bitmap);
}
});
}
/**
* 根据url下载图片
*/
public Bitmap downImage(String imageUrl) {
Bitmap bitmap = null;
try {
URL url = new URL(imageUrl);
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
bitmap = BitmapFactory.decodeStream(conn.getInputStream());
conn.disconnect();
} catch (Exception e) {
e.printStackTrace();
}
return bitmap;
}
}
public class ImageCache {
// 图片缓存
LruCache<String, Bitmap> mImageCache;
public ImageCache(){
initImageCache();
}
/**
* 初始化图片的缓存
*/
private void initImageCache(){
// 计算可用的最大内存(千字节kb)，
// Runtime.getRuntime().maxMemory()返回尝试使用的最大内存量，以字节为单位。
int maxMemory = (int) (Runtime.getRuntime().maxMemory()/1024);
// 取1/4的可用内存作为缓存
int cacheSize = maxMemory/4;
mImageCache = new LruCache<String, Bitmap>(cacheSize){
// 每一项的大小
@Override
protected int sizeOf(String key, Bitmap bitmap) {
// Bitmap所占用的内存空间数等于Bitmap的每一行所占用的空间数乘以Bitmap的行数
// 即bitmap的行字节*高度
return bitmap.getRowBytes()*bitmap.getHeight()/1024;
}
};
}
/**
* 存储图片
*/
public void put(String url, final Bitmap bitmap){
mImageCache.put(url, bitmap);
}
/**
* 根据url获取图片
*/
public Bitmap get(String url) {
return mImageCache.get(url);
}
}
将ImageLoader一拆为二，ImageLoader只负责图片加载的逻辑，ImageCache只负责处理图片缓存的逻辑，这样ImageLoader的代码量少了，职责也清晰了；当与缓存相关的逻辑需要修改时，不需要修改ImageLoader类，而图片加载的逻辑需要修改时，也不会影响到缓存处理逻辑。经过修改结构变得清晰了，但是扩展性还是比较欠缺。
开闭原则
开闭原则的英文全称是Open Close Principle，缩写是OCP，它是Java世界里最基础的设计原则，它指导我们如何建立一个稳定的、灵活的系统。开闭原则的定义是：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是对于修改是封闭的。
在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会将错误引入原本已经经过测试的旧代码中，破坏原有系统。因此，当软件需要变化时，我们应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。
当然，在现实开发中，只通过继承的方式来升级、维护原有原有系统只是一个理想化的愿景，因此，在实际的开发过程中，修改原有代码、扩展代码往往是同时存在的。
软件开发过程中，最不会变化的就是变化本身。产品需要不断地升级、维护，没有一个产品从第一版本开发完就再没有变化了，除非在下个版本诞生之前它已经被终止。而产品需要升级、修改原来的代码就可能会引发其他的问题。那么，如何确保原有软件模块的正确性，以及尽量少地影响原有模块，答案就是尽量遵守开闭原则。
上次重构之后的ImageLoader职责单一、结构清晰，但是随着用户的增多，缓存系统的问题也就暴露出来了，通过内存缓存解决了每次从网络加载图片的问题，但是，Android应用的内存很有限，且具有易失性，即当应用重新启动之后，原来已经加载过的图片将会丢失，这样重启之后就需要重新下载！这又会导致加载缓慢、耗费用户浏量的问题。
解决问题：引入SD卡缓存，下载过的图片就会缓存到本地，即使重启应用也不需要重新下载了。
public class DiskCache {
static String cacheDir = "sdcard/cache/";
/**
* 从缓存中获取图片
*/
public Bitmap get(String url){
return BitmapFactory.decodeFile(cacheDir + url);
}
/**
* 根据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();
} finally {
if(fileOutputStream != null){
try{
fileOutputStream.close();
} catch(IOException e){
e.printStackTrace();
}
}
}
}
}
public class ImageLoader {
// 内存缓存
ImageCache mImageCache = new ImageCache();
// SD卡缓存
DiskCache mDiskCache = new DiskCache();
// 是否使用SD卡缓存
boolean isUseDiskCache = false;
// 线程池，线程数量为CPU的数量
ExecutorService mExecutorService = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());
/**
* 在ImageView中显示图片
*/
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;
}
// 没有缓存，则提交给线程池进行下载
imageView.setTag(url);
mExecutorService.execute(new Runnable() {
@Override
public void run() {
Bitmap bitmap = downImage(url);
if (bitmap == null) {
return;
}
if (imageView.getTag().equals(url)) {
imageView.setImageBitmap(bitmap);
}
mImageCache.put(url, bitmap);
}
});
}
/**
* 根据url下载图片
*/
public Bitmap downImage(String imageUrl) {
Bitmap bitmap = null;
try {
URL url = new URL(imageUrl);
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
bitmap = BitmapFactory.decodeStream(conn.getInputStream());
conn.disconnect();
} catch (Exception e) {
e.printStackTrace();
}
return bitmap;
}
public void useDiskCache(boolean useDiskCache){
isUseDiskCache = useDiskCache;
}
}
从上面的代码中可以看到，新增了一个DiskCache类和在ImageLoader类中加入了少量代码，这样就增加了SD卡缓存的功能，用户可以通过useDiskCache(boolean)方法来设置使用哪种缓存。
经过修改是解决了一些问题，但是在缓存策略上还是出现了明显的问题：使用内存缓存时，就不能使用SD卡缓存；使用SD卡缓存时，就不能使用内存缓存。最好的缓存策略：用户是需要这两种缓存的综合，首先使用内存缓存，如果内存缓存中没有图片再使用SD卡缓存，如果SD卡缓存中也没有图片最后从网络上获取。
/**
* 双缓存。先从内存缓存中取，如没有，再从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);
}
}
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());
/**
* 在ImageView中显示图片
*/
public void displayImage(final String url, final ImageView imageView){
Bitmap bitmap = null;
if(isUseDoubleCache){
bitmap = mDoubleCache.get(url);
} else if(isUseDiskCache){
bitmap = mDiskCache.get(url);
} else {
bitmap = mImageCache.get(url);
}
if(bitmap != null){
imageView.setImageBitmap(bitmap);
return;
}
// 没有缓存，则提交给线程池进行下载
imageView.setTag(url);
mExecutorService.execute(new Runnable() {
@Override
public void run() {
Bitmap bitmap = downImage(url);
if (bitmap == null) {
return;
}
if (imageView.getTag().equals(url)) {
imageView.setImageBitmap(bitmap);
}
mImageCache.put(url, bitmap);
}
});
}
/**
* 根据url下载图片
*/
public Bitmap downImage(String imageUrl) {
Bitmap bitmap = null;
try {
URL url = new URL(imageUrl);
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
bitmap = BitmapFactory.decodeStream(conn.getInputStream());
conn.disconnect();
} catch (Exception e) {
e.printStackTrace();
}
return bitmap;
}
public void useDiskCache(boolean useDiskCache){
isUseDiskCache = useDiskCache;
}
public void useDoubleCache(boolean useDoubleCache){
isUseDoubleCache = useDoubleCache;
}
}
这样就修改完成了，这一次基本解决了这个缓存策略的问题。但是，每次增加新的缓存方法时都要修改原来的代码，这样很可能会引入Bug，而且会使原来的代码逻辑变得越来越复杂，并且用户也不能自定义缓存的实现。
软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是对于修改是封闭的，这就是开放关闭原则。也就是说，当软件需要变化时，我们应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。
展示先UML类图：
按照新的UML类图，对程序进行一次重构。
public class ImageLoader {
// 图片缓存
ImageCache mImageCache = new ImageCache();
// 线程池，线程数量为CPU的数量
ExecutorService mExecutorService = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());
// 注入缓存实现
public void setImageCache(ImageCache cache){
mImageCache = cache;
}
/**
* 在ImageView中显示图片
*/
public void displayImage(final String url, final ImageView imageView){
Bitmap bitmap = mImageCache.get(url);
if(bitmap != null){
imageView.setImageBitmap(bitmap);
return;
}
// 没有缓存，则提交给线程池进行下载
submitLoadRequest(url, imageView);
}
private void submitLoadRequest(final String url, final ImageView imageView){
imageView.setTag(url);
mExecutorService.execute(new Runnable() {
@Override
public void run() {
Bitmap bitmap = downImage(url);
if (bitmap == null) {
return;
}
if (imageView.getTag().equals(url)) {
imageView.setImageBitmap(bitmap);
}
mImageCache.put(url, bitmap);
}
});
}
/**
* 根据url下载图片
*/
public Bitmap downImage(String imageUrl) {
Bitmap bitmap = null;
try {
URL url = new URL(imageUrl);
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
bitmap = BitmapFactory.decodeStream(conn.getInputStream());
conn.disconnect();
} catch (Exception e) {
e.printStackTrace();
}
return bitmap;
}
}
// 将原来的ImageCache类提取成图片缓存接口
public interface ImageCache{
public Bitmap get(String url);
public void put(String url, Bitmap bitmap);
}
public class MemoryCache implements ImageCache{
// 图片缓存
LruCache<String, Bitmap> mMemoryCache;
public MemoryCache(){
initMemoryCache();
}
/**
* 初始化图片的缓存
*/
private void initMemoryCache(){
// 计算可用的最大内存(千字节kb)，
// Runtime.getRuntime().maxMemory()返回尝试使用的最大内存量，以字节为单位。
int maxMemory = (int) (Runtime.getRuntime().maxMemory()/1024);
// 取1/4的可用内存作为缓存
int cacheSize = maxMemory/4;
mMemoryCache = new LruCache<String, Bitmap>(cacheSize){
// 每一项的大小
@Override
protected int sizeOf(String key, Bitmap bitmap) {
// Bitmap所占用的内存空间数等于Bitmap的每一行所占用的空间数乘以Bitmap的行数
// 即bitmap的行字节*高度
return bitmap.getRowBytes()*bitmap.getHeight()/1024;
}
};
}
/**
* 存储图片
*/
public void put(String url, Bitmap bitmap){
mMemoryCache.put(url, bitmap);
}
/**
* 根据url获取图片
*/
public Bitmap get(String url) {
return mMemoryCache.get(url);
}
}
public class DiskCache implements ImageCache {
static String cacheDir = "sdcard/cache/";
/**
* 从缓存中获取图片
*/
public Bitmap get(String url){
return BitmapFactory.decodeFile(cacheDir + url);
}
/**
* 根据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();
} finally {
if(fileOutputStream != null){
try{
fileOutputStream.close();
} catch(IOException e){
e.printStackTrace();
}
}
}
}
}
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已经基本算合格了。
里氏替换原则
里氏替换原则英文全称是Liskov Substitution Principle，缩写是LSP。对于它的定义，有两种，第一种不太好理解，第二种直接了当。
LSP的第一种定义：如果对每一个类型为S的对象O1，都有类型为T的对象O2，使得以T定义的所有程序P在所有的对象O1都替换成O2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。
LSP的第二种定义：所有引用基类的地方必须能透明地使用其子类的对象。
面向对象的语言有三大特点：继承、封装、多态。LSP就是依赖于继承、多态这两大特性。LSP根据第二种定义，通俗来讲：只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本不需要知道是父类还是子类；反过来就不行了，有子类出现的地方，父类未必就能适应。其实最终总结就两字：抽象。
我们通过Android中的Window和View的关系来理解一下，画一个简单的UML类图：
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(){
// 绘制按钮
}
}
public class TextView extends View {
public void draw(){
// 绘制文本
}
}
上面示例中，Window依赖于View，而View是一个抽象类，measure()方法是View各个子类共享的方法，draw()方法是抽象方法，子类通过覆写draw()实现各自特色的功能。任何继承自View类的子类都可以设置给show()方法，这就是LSP。
LSP核心原理是抽象，抽象又依赖于继承这个特性，在面向对象编程（OOP）当中，继承的优缺点都相当明显。
优点：
- 代码重用，减少创建类的成本，每个子类都拥有父类的属性和方法
- 子类与父类基本相似，但又与父类有所区别
- 提高代码的可扩展性
缺点：
- 继承是侵入性的，只要继承就必须拥有父类的所有属性和方法
- 可能造成子类代码冗余、灵活性降低，因为子类必须拥有父类的所有属性和方法
上一节中MemoryCache、DiskCache、DoubleCache都可以替换ImageCache的工作，并且能够保证行为的正确性，这就是LSP。只不过上一节是接口，这里是抽象类，然而它们有个共同点就是抽象。开闭原则和LSP都强调抽象，因此，在开发过程中运用抽象是走向代码优化的重要一步。
依赖倒置原则
依赖倒置原则英文全称是Dependence Inversion Principle，缩写是DIP。DIP指一种特定的解耦形式，使得高层次的模块不依赖于低层次的模块的实现细节的目的，依赖模块被颠倒了。
这个概念不好理解，DIP有几个关键点：
- 高层模块不应该依赖低层模块，两者都应该依赖其抽象
- 抽象不应该依赖细节
- 细节应该依赖抽象
在Java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或者继承抽象类而产生的类就是细节，其特点就是，可以直接被实例化，也就是可以new出来。高层模块就是调用端，低层模块就是具体实现类。DIP在Java语言中的表现就是：模块间的依赖通过抽象产生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。一句话概括为：面向抽象编程，抽象指接口或抽象类。面向抽象编程是面向对象精髓之一。
如果类与类直接依赖于细节，那么它们之间就有直接的耦合，当具体实现需要变化时，意味着要同时修改依赖者的代码，这限制了系统的可扩展性。
接口隔离原则
接口隔离原则英文全称是Interface Segregation Principle，缩写是ISP。
ISP的定义是：客户端不应该依赖它不需要的接口。另一种定义是：类间的依赖关系应该建立在最小的接口上。
ISP将非常庞大、臃肿的接口拆分成更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。
ISP的目的是系统解开耦合，从而容易重构、更改和重新部署。
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();
}
}
}
}
上面这段代码，各种try catch嵌套都是些简单的代码，但是会严重影响代码的可读性，并且多层级的大括号很容易将代码写到错误的层级中。Java中有一个Closeable接口，该接口标识了一个可关闭的对象，它只有一个close方法。FileOutputStream类就实现了这个接口，既然实现了Closeable接口，那么建一个方法来关闭它就可以了。写了如下工具类：
public final class CloseUtils {
private CloseUtils(){}
public static void closeQuietly(Closeable closeable){
if(null!=closeable){
try{
closeable.close();
}catch(IOException e){
e.printStackTrace();
}
}
}
}
那么使用该工具类之后的代码：
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{
CloseUtils.closeQuietly(fileOutputStream);
}
}
代码简洁了许多，而且closeQuietly方法可以运用到各类可关闭的对象中，保证了代码的重用性。该方法的基本原理就是依赖于Closeable抽象而不是具体实现，并且建立在最小化依赖原则上，它只需要知道这个对象是可关闭的，其他的一概不关心，也就是这里的接口隔离原则。
迪米特原则
迪米特原则英文全称是Law of Demeter，缩写是LOD，也成为最少知识原则（Least Knowledge Principle）。内容：一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，类的内部如何实现与调用者或者依赖者没关系，调用者或者依赖者只需要知道它需要的方法即可，其他的可一概不用管。
LOD还有一个英文解释：Only talk to your immedate friends，翻译过来就是：只与直接的朋友通信。每个对象都必然会与其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系的类型很多，如组合、聚合、依赖等。
那以租房为例来讲讲LOD。租户只要求房间的面积和租金，其他一概不管，中介将符合租户要求的房子提供给租户。
public class Room {
public float area;
public float price;
public Room(float area, float price){
this.area = area;
this.price = price;
}
}
public class Mediator {
List<Room> mRooms = new ArrayList<Room>();
public Mediator(){
for(int i=0; i<5; i++){
mRooms.add(new Room(14+i, (14+i)*150));
}
}
public List<Room> getAllRoom(){
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){
List<Room> rooms = mediator.getAllRoom();
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类打交道。租户的要求只是通过中介找到一间适合自己的房间罢了，如果把这些检测条件都放在Tenant类中，那么中介类的功能就被弱化，而且导致Tenant与Room的耦合较高，因为Tenant必须知道许多关于Room的细节。
既然是耦合太严重，那只能解耦了。首先要明确的是，租户只和租户的朋友通信，就是中介。
public class Room {
public float area;
public float price;
public Room(float area, float price){
this.area = area;
this.price = price;
}
}
public class Mediator {
List<Room> mRooms = new ArrayList<Room>();
public Mediator(){
for(int i=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.diffArea;
}
}
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));
}
}
“只与直接的朋友通信”这简单的几个字就能够将我们从复杂的关系网中抽离出来，使程序耦合度更低、稳定性更好。