开发者社区> 异步社区> 正文

《Android 源码设计模式解析与实战》——第1章,第1.6节更好的可扩展性——迪米特原则

简介:
+关注继续查看

本节书摘来自异步社区《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所示。


bfa1e2157c78f92f0e148dcfdb9ab5b5d128e63f

既然是耦合太严重,那我们就只能解耦了。首先要明确的是,我们只和我们的朋友通信,这里就是指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所示。


1818d4b5ac87a9c88c9d00f82cddc494927356f9

只是将对于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将一切细节隐藏在了直接“朋友”的外衣之下,使得系统具有更低的耦合性和更好的可扩展性。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
《设计模式解析(第2版•修订版)》—第1章 1.8节特殊对象方法
所有面向对象语言都会在对象删除时查找并执行相应的析构函数。与构造函数一样,析构函数的使用也是对象“自己负责自己”所要求的。
1213 0
《设计模式解析(第2版•修订版)》—第1章 1.5节应对需求变更
为了找出解决需求变更问题的办法,弄清功能分解有没有其他替代方法,我们先来看看日常生活中人们是如何做事的。假设你是要在一个会议1上担任讲师,听课的人在课后还要去听其他课,但他们不知道下一堂课的听课地点。你的责任之一,就是确保大家都知道下一堂课去哪里上。
1368 0
《数据分析实战 基于EXCEL和SPSS系列工具的实践》一1.2 数据分析能给我们带来什么
曾有人在培训时提出,我公司的业务状况,我非常清楚,还用得着分析吗?可是,事实真的是这样吗?你真的对公司的数据了如指掌?对它所体现的特征一清二楚?如果公司的数据量比较大、比较复杂,那么它就有可能存在潜在的价值,就有分析的必要。
1181 0
深入理解设计模式!六大设计原则的分析与介绍
本篇文章开始介绍程序架构设计中的设计模式,介绍了设计模式的基本概念以及23设计模式。主要介绍了设计模式中的六大设计原则。开闭原则,里氏代换原则,依赖倒转原则,接口隔离原则,迪米特原则和合成复用原则。这几大原则是设计模式使用的基础,在使用设计模式时,应该牢记这六大原则。
120 0
《设计模式解析(第2版•修订版)》—第1章 1.7节面向对象程序设计实践
对象对自己行为所负的责任越多,控制程序需要负的责任就越少。封装使对象内部行为的变化对其他对象变得透明了。封装有助于防止不良副作用。
1379 0
《设计模式解析(第2版•修订版)》—第1章 1.6节面向对象范型
面向对象范型以对象概念为中心,一切都集中在对象上。编写代码时是围绕对象而非函数进行组织的。
1423 0
Dubbo源码解析实战 - 路由Router的奥秘
Dubbo源码解析实战 - 路由Router的奥秘
30 0
OKHTTP3源码和设计模式(下篇)
  在《OKHTTP3源码和设计模式(上篇)》,中整体介绍了 OKHttp3 的源码架构,重点讲解了请求任务的分发管理和线程池以及请求执行过程中的拦截器。
930 0
+关注
异步社区
异步社区(www.epubit.com)是人民邮电出版社旗下IT专业图书旗舰社区,也是国内领先的IT专业图书社区,致力于优质学习内容的出版和分享,实现了纸书电子书的同步上架,于2015年8月上线运营。公众号【异步图书】,每日赠送异步新书。
12049
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
JS零基础入门教程(上册)
立即下载
性能优化方法论
立即下载
手把手学习日志服务SLS,云启实验室实战指南
立即下载