系统有更高的灵活性------接口隔离原则
【一】定义
客户端不应该依赖它不需要的接口。另一种定义是:类间的依赖关系应该建立在最小的接口上。接口隔离原则将非常庞大、臃肿的几口拆分成更小的和更具体的接口,这样客户将会只需要知道他们感兴趣的方法。说白了就是让客户端依赖的接口尽可能地小。
【二】例子
//将图片缓存到内存中
private void put(String url, Bitmap bitmap){
FileOutputStream fileOutputStream=null;
try {
fileOutputStream =new FileOutputStream(getCacheDir()+url);
bitmap.compress(Bitmap.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类就实现了这个接口,意味着,在关闭这100多个类型的对象时,都需要写出像put方法中finally代码段那样的代码。
既然都实现了Closeable接口,那只要我建一个方法来统一关闭这些对象不久可以了么?
所以就有了如下工具类:
public final class CloseUtils{
/**
* 关闭CloseUtils对象
* @param closeable
*/
public static void closeQuietly(Closeable closeable){
if (null!=closeable){
try {
closeable.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
}
运用:
private void put(String url, Bitmap bitmap){
FileOutputStream fileOutputStream=null;
try {
fileOutputStream =new FileOutputStream(getCacheDir()+url);
bitmap.compress(Bitmap.CompressFormat.PNG,100,fileOutputStream);
} catch (FileNotFoundException e) {
e.printStackTrace();
}finally {
CloseUtils.closeQuietly(fileOutputStream);
}
}
可以看到代码简洁了很多,CloseUtils的closeQuietly方法的基本原理就是依赖于Closeable抽象而不是具体实现,并且建立在最小化依赖原则的基础上,它只需要知道这个对象是可关闭,其他的一概不关心,也就是这里的接口隔离原则。
更好的扩展性--------迪米特原则
【一】定义
一个对象应该对其他对象有最少的了解。通俗地讲,一个类应该对自己需要耦合或者调用的类知道得最少,类得内部如何实现于调用者或者依赖者没关系,调用者或者依赖者只需要知道它需要得方法即可,其他得可一概不用管。
【二】例子
以租房为例,租客通过中介找房。我们设定情况为:我只要求房间得面积和租金,其他得一概不管,中介将符合我要求得房子提供给我就可以。
/**
* 房间
*/
public class Room {
public float area;
public float price;
public Room(float area, float price) {
this.area = area;
this.price = price;
}
@NonNull
@Override
public String toString() {
return "Room[area =" + area + ",price=" + price + "]";
}
}
/**
* 中介
*/
public class Mediator {
List<Room> mRooms = new ArrayList<>();
public Mediator() {
for (int i = 0; i < 5; i++) {
mRooms.add(new Room(14 + i, (14 + i) * 150));
}
}
public List<Room> getmRooms() {
return mRooms;
}
}
public class Tenant {
public float roomArea;
public float roomPrice;
public static final float diffPrice = 100.00001f;
public static final float diffArea = 0.1111f;
public void rentRoom(Mediator mediator) {
List<Room> rooms = mediator.getmRooms();
for (Room r : rooms) {
if (isSuitable(r)) {
System.out.println("租到房子啦!"+r);
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的细节。当Room变化时Tenant也必须跟着变化。Tenant又与Mediator耦合,这就出现了纠缠不清的关系。
所以需要重构:
/**
* 中介
*/
public class Mediator {
List<Room> mRooms = new ArrayList<>();
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 r : mRooms) {
if (isSuitable(area,price,r)) {
return r;
}
}
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.00001f;
public static final float diffArea = 0.1111f;
public void rentRoom(Mediator mediator){
System.out.println("租到房子啦"+mediator.rentOut(roomArea,roomPrice));
}
}
只是将对于Room的判定操作移到了Mediator类中,这本该时Mediator的职责没根据租户设定的条件查找符合要求的房子,并且将结果交到租户就可以了。租户并不需要知道太多关于Room的细节。