本节书摘来自异步社区《Android 源码设计模式解析与实战》一书中的第1章，第1.6节更好的可扩展性——迪米特原则，作者 何红辉 , 关爱民，更多章节内容可以访问云栖社区“异步社区”公众号查看
1.6 更好的可扩展性——迪米特原则迪米特原则英文全称为Law of Demeter，缩写是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<Room> mRooms = new ArrayList<Room>(); public Mediator() { for (inti = 0; i < 5; i++) { mRooms.add(new Room(14 + i, (14 + i) * 150)); } } public List<Room>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<Room>rooms = 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类打交道。租户类的要求只是通过中介找到一间适合自己的房间罢了，如果把这些检测条件都放在Tenant类中，那么中介类的功能就被弱化，而且导致Tenant与Room的耦合较高，因为Tenant必须知道许多关于Room的细节。当Room变化时Tenant也必须跟着变化。Tenant又与Mediator耦合，这就出现了纠缠不清的关系。这个时候就需要我们分清谁才是我们真正的“朋友”，在我们所设定的情况下，显然是Mediator（虽然现实生活中不是这样的）。上述代码的结构如图1-5所示。
既然是耦合太严重，那我们就只能解耦了。首先要明确的是，我们只和我们的朋友通信，这里就是指Mediator对象。必须将Room相关的操作从Tenant中移除，而这些操作案例应该属于Mediator。我们进行如下重构：
/** * 中介 */ public class Mediator { List<Room> mRooms = new ArrayList<Room>(); 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)); } }重构后的结构图如图1-6所示。
只是将对于Room的判定操作移到了Mediator类中，这本应该是Mediator的职责，根据租户设定的条件查找符合要求的房子，并且将结果交给租户就可以了。租户并不需要知道太多关于Room的细节，比如与房东签合同，房东的房产证是不是真的，房内的设施坏了之后要找谁维修等。当我们通过我们的“朋友”——中介租了房之后，所有的事情我们都通过与中介沟通就好了，房东、维修师傅等这些角色并不是我们直接的“朋友”。“只与直接的朋友通信”这简单的几个字就能够将我们从复杂的关系网中抽离出来，使程序耦合度更低、稳定性更好。
通过上述示例以及小民的后续思考，迪米特原则这把利剑在小民的手中已经舞得风生水起。就拿SD卡缓存来说吧，ImageCache就是用户的直接朋友，而SD卡缓存内部却是使用了jake wharton的DiskLruCache实现，这个DiskLruCache就不属于用户的直接朋友了，因此，用户完全不需要知道它的存在，用户只需要与ImageCache对象打交道即可，如将图片存到SD卡中的代码如下：
public void put(String url, Bitmap value) { DiskLruCache.Editor editor = null; try { // 如果没有找到对应的缓存，则准备从网络上请求数据，并写入缓存 editor = mDiskLruCache.edit(url); if (editor != null) { OutputStream outputStream = editor.newOutputStream(0); if (writeBitmapToDisk(value, outputStream)) { // 写入Disk缓存 editor.commit(); } else { editor.abort(); } CloseUtils.closeQuietly(outputStream); } } catch (IOException e) { e.printStackTrace(); } }用户在使用SD卡缓存时，根本不知道DiskLruCache的实现，这就很好地对用户隐藏了具体实现。当小民已经“牛”到可以自己完成SD卡的LRU实现时，他就可以随心所欲地替换掉jake wharton的DiskLruCache。小民的代码大体如下：
@Override public void put(String url, Bitmap bmp) { // 将Bitmap写入文件中 FileOutputStream fos = null; try { // 构建图片的存储路径 ( 省略了对url取md5) fos = new FileOutputStream("sdcard/cache/" + imageUrl2MD5(url)); bmp.compress(CompressFormat.JPEG, 100, fos); } catch (FileNotFoundException e) { e.printStackTrace(); } finally { if ( fos != null ) { try { fos.close(); } catch (IOException e) { e.printStackTrace(); } } } // end if finally }SD卡缓存的具体实现虽然被替换了，但用户根本不会感知到。因为用户根本不知道DiskLruCache的存在，他们没有与DiskLruCache进行通信，他们只认识直接“朋友”——ImageCache，ImageCache将一切细节隐藏在了直接“朋友”的外衣之下，使得系统具有更低的耦合性和更好的可扩展性。
