声明:本系列博客整理来源于《Android源码设计模式解析与实战》,仅作为个人学习总结记录,任何组织和个人不得转载进行商业活动!
赶在2018年最后的几天里,把之前拖延的后三个原则终于总结完成,还算圆满。这样就可以踏实地喜迎2019了。
LOD,也称为最少知识原则(Least Knowledge Principle)。虽然名字不同,但描述的是同一个原则:一个对象应该对其他对象有最少的了解。通俗地讲,一个类应该对自己需要耦合或调用的类知道得最少,类的内部如何实现与调用者或者依赖者没有关系,调用者或者依赖者只需要知道它需要的方法即可,其他的一概不用管。类与类之间的关系越密切,耦合度越大,当一个类发生变化时,对另一个类的影响也越大。
迪米特法则还有一个英文解释是Only talk to your immedate friends,翻译过来就是:只与直接的朋友通信。什么叫做直接的朋友呢?每个对象都必然会与其他对象有耦合关系,两个对象之后的耦合就成为朋友关系,这种关系的类型有很多,如组合、聚合、依赖等。
下面我们就以租房为例来讲讲迪米特原则的应用。
“北漂”的朋友比较了解,在北京租房绝大多数都是通过中介找房。我们设定的情况为:我只要求房间的面积和租金,其他的一概不管,中介将符合我要求的房子提供给我就可以。代码实现如下:
/**
* 房间
*/
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 (int i = 0;i<5;i++){
mRooms.add(new Room(14+i,(14+i)*150));
}
}
public List getAllRooms(){
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 rooms = mediator.getAllRooms();
for (Room room:rooms){
if(isSuitable(room)){
System.out.print("租到房间啦!"+room);
break;
}
}
}
private boolean isSuitable(Room room) {
return Math.abs(room.price - roomPrice)
从上面的代码中可以看到,Tenant不仅依赖了Mediator类,还需要频繁地与Room类打交道。租户类的要求只是通过中介找到一件适合自己的房子罢了,如果把这些检测条件都放在Tenant类中,那么中介类的功能就被弱化,而且倒置Tenant与Room的耦合较高,因为Tenant必须知道许多关于Room的细节。当Room变化时Tenant也必须跟着变化。Tenant又与Mediator耦合,这就出现了纠缠不清的关系。这个时候就需要我们分清谁才是我们真正的“朋友”,在我们所设定的情况下,显然是Mediator(虽然现实生活中不是这样的)。上述的代码结果UML图如下:
既然是耦合太严重,那我们就只能解耦了。首先要明确的是,我们只和我们的朋友通信,这里就是指Mediator对象。必须将Room相关的操作从Tenant中移除,而这些操作案例应该属于Mediator。我们进行如下重构:
/**
* 中介
*/
public class Mediator {
List 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 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)
重构后的结构图如下所示:
只是将对于Room的判定操作移到了Mediator类中,这本应该是Mediator的职责,根据租户设定的条件查找符合要求的房子,并且将结果交给租户就可以了。租户并不需要知道太多关于Room的细节,比如与房东签合同,房东的房产证是不是真的,房内的设施坏了之后要找谁谁维修等。当我们通过我们的“朋友”——中介租了房之后,所有的事情我们都通过与中介沟通就好了,房东、维修师傅等这些角色并不是我们直接的“朋友”。“只与直接的朋友通信”这简单的几个字就能够将我们从复杂的关系网中抽离出来,使程序耦合度更低、稳定性更好。
通过上述示例以及小民的后续思考,迪米特原则这把利剑在小民的手中已经舞得风生水起。就拿SD卡缓存来说吧,ImageLoader就是用户的直接朋友,而SD卡缓存内部却是使用了jake wharton 的DiskLruCache实现,这个DiskLruCache就不属于用户的直接朋友了,因此,用户完全不需要知道它的存在,用户只需要与ImageCache对象打交道即可,如将图片存到SD卡中的代码如下:
public void put(String url,Bitmap bitmap){
DiskLruCache.Editor editor = null;
try {
//如果没有找到对应的缓存,则准备从网络上请求数据,并写入缓存
editor = mDiskLruCache.edit(url);
if(editor != null){
OutputStream outputStream = editor.newOutputStream(0);
if(writeBitmapToDisk(bitmap,outputStream)){
//写入Disk缓存
editor.commit();
}else{
editor.abort();
}
CloseUtils.closeQuitely(outputStream);
}
}catch (IOException e){
e.printStackTrace();
}
}
用户在使用SD卡缓存时,根本不知道DiskLruCache的实现,这就很好的对用户隐藏了具体实现。当小民已经“牛”到可以自己完成SD卡的LRU实现时,他就可以随心所欲地替换掉jake wharton的DiskLruCache。小民的代码大体如下:
public void put(String url,Bitmap bitmap){
FileOutputStream fos = null;
try {
//构建图片的存储路径(省略了对URL取md5)
fos = new FileOutputStream("sdcard/cache/"+imageUrl2MD5(url));
bitmap.compress(Bitmap.CompressFormat.JPEG,100,fos);
}catch (FileNotFoundException e){
e.printStackTrace();
}finally {
CloseUtils.closeQuitely(fos);
}
}
SD卡缓存的具体实现虽然被替换了,但用户根本不会感知到。因为用户根本不知道DiskLruCache的存在,他们没有与DiskLruCahce进行通信,他们只认识直接“朋友”——ImageCache,ImageCache将一切细节隐藏在了直接“朋友”的外衣之下,使得系统具有更低的耦合性和更好的可扩展性。
<<点击 - 面向对象的六大原则之接口隔离原则