嘻哈说:设计模式之迪米特法则

栏目: 后端 · 发布时间: 6年前

内容简介:在我们刚开始学习编程的时候,通常会将所有的方法都声明为public,例如:厨师类。客人类。

在我们刚开始学习编程的时候,通常会将所有的方法都声明为public,例如:

package com.fanqiekt.principle.lod;

/**
 * 厨师
 *
 * @author 番茄课堂-懒人
 */
public class Chef{
    public String flavour = "秘制调料XXX";

    /**
     * 做饭
     * @param dishName 下单的菜名
     */
    public void cooking(String dishName) {
        System.out.println("开始烹饪:"+dishName);

        switch (dishName){
            case "西红柿炒鸡蛋":
                cookingTomato();
                break;
            case "酸辣土豆丝":
                cookingPotato();
                break;
        }

        System.out.println(dishName + "出锅");
    }

    /**
     * 炒西红柿鸡蛋
     */
    public void cookingTomato() {
        System.out.println("放入调料:" + flavour);
        System.out.println("先炒鸡蛋");
        System.out.println("再炒西红柿");
        System.out.println("...");
    }

    /**
     * 炒酸辣土豆丝
     */
    public void cookingPotato() {
        System.out.println("放入调料:" + flavour);
        System.out.println("先放葱姜蒜");
        System.out.println("再放土豆丝");
        System.out.println("...");
    }
}
复制代码

厨师类。

package com.fanqiekt.principle.lod;

/**
 * 客人
 * @Author: 番茄课堂-懒人
 */
public class Client {
    public static void main(String[] args){
        Chef chef = new Chef();
        chef.cooking("西红柿炒鸡蛋");
        System.out.println("-------");
        chef.cooking("酸辣土豆丝");
    }
}
复制代码

客人类。

这样做好不好?

大家可以先思考下。

2、定义

我们先来看一下迪米特法则的定义。

又称为最少知识原则。

一个软件实体应当尽可能少地与其他实体发生相互作用。

这个比较好理解,一个类尽可能少的与其他的类产生关联,低耦合,高内聚嘛。

迪米特法则包含两种角色:依赖者与被依赖者。

3、含义

我们回到疑惑中的问题,Chef类好不好?

首先,Chef类的角色是被依赖者。

它暴露了flavour属性,这是存在问题的,有哪个厨师愿意把自己的独家配方公开出去啊。

而且它还暴露了依赖者并不关心cookingTomato、cookingPotato两个方法。

对于依赖者来说,我只需要调用cooking方法就可以了,至于菜具体怎么做,就与我无关了。

并且暴露的话,程序员也容易懵逼,这两个方法是干嘛的?我要不要研究下?

所以,

从被依赖者的角度来说:只暴露应该暴露的方法或者属性。

有个简单的套路:

可以用private就绝不用protected,可以用protected就绝不用public。

那Client类总没什么问题了吧。

确实,乍一看感觉没有任何问题的,再乍乍一看还是感觉没有问题。。。

它的不合适不是从语法调用方面看的,而是从依赖关系。

客人是不可以直接依赖厨师的,而应该依赖服务员。

在实际项目中,很可能会存在客人类依赖了厨师类、服务员类,而服务员类又依赖了厨师类。

这会让代码非常混乱,也违背了迪米特法则。

所以,

从依赖者的角度来说:只依赖应该依赖的对象。

4、代码

我们按照迪米特法则优化下代码。

package com.fanqiekt.principle.lod;

/**
 * 厨师
 *
 * @author 番茄课堂-懒人
 */
public class Chef{
    private String flavour = "秘制调料XXX";

    /**
     * 做饭
     * @param dishName 下单的菜名
     */
    public void cooking(String dishName) {
        System.out.println("开始烹饪:"+dishName);

        switch (dishName){
            case "西红柿炒鸡蛋":
                cookingTomato();
                break;
            case "酸辣土豆丝":
                cookingPotato();
                break;
        }

        System.out.println(dishName + "出锅");
    }

    /**
     * 炒西红柿鸡蛋
     */
    private void cookingTomato() {
        System.out.println("放入调料:" + flavour);
        System.out.println("先炒鸡蛋");
        System.out.println("再炒西红柿");
        System.out.println("...");
    }

    /**
     * 炒酸辣土豆丝
     */
    private void cookingPotato() {
        System.out.println("放入调料:" + flavour);
        System.out.println("先放葱姜蒜");
        System.out.println("再放土豆丝");
        System.out.println("...");
    }
}
复制代码

flavour声明为private,其他类就不可访问了,避免泄漏秘制调料。

cookingTomato、cookingPotato声明为private

cooking需要依赖者调用,所以依旧为public。

package com.fanqiekt.principle.lod;

/**
 * 服务员
 *
 * @author 番茄课堂-懒人
 */
public class Waiter {
    private Chef chef = new Chef();

    /**
     * 点餐
     * @param dishName 餐名
     */
    public void order(String dishName) {
        System.out.println("客人点餐:"+dishName);

        chef.cooking(dishName);

        System.out.println(dishName+"上桌啦,请您品尝!");
    }
}
复制代码

服务员类,依赖了Chef对象,并声明为private。

package com.fanqiekt.principle.lod;

/**
 * 客人
 * @Author: 番茄课堂-懒人
 */
public class Client {
    public static void main(String[] args){
        Waiter waiter = new Waiter();
        waiter.order("西红柿炒鸡蛋");
        System.out.println("-------");
        waiter.order("酸辣土豆丝");
    }

}
复制代码

客人类,依赖了Waiter类。。

客人点餐:西红柿炒鸡蛋
开始烹饪:西红柿炒鸡蛋
放入调料:秘制调料XXX
先炒鸡蛋
再炒西红柿
...
西红柿炒鸡蛋出锅
西红柿炒鸡蛋上桌啦,请您品尝!
-------
客人点餐:酸辣土豆丝
开始烹饪:酸辣土豆丝
放入调料:秘制调料XXX
先放葱姜蒜
再放土豆丝
...
酸辣土豆丝出锅
酸辣土豆丝上桌啦,请您品尝!
复制代码

运行结果。

5、优点

降低风险

避免不该暴露的方法或者属性暴露,从而规避风险。

避免依赖关系过于混乱。

6、嘻哈说

接下来,请您欣赏 迪米特法则的原创歌曲

嘻哈说:迪米特法则
作曲:懒人
作词:懒人
Rapper:懒人

哥们是个大厨
身材有些发福
您可以让我做饭甚至是打卤
但您无权知晓我具体是油煎炸煮
这是我的秘密才能把客人抓住
这就是最小知识原则的迪米特法则
一个实体尽少与其他产生瓜葛
依赖者只依赖应该依赖的对象绝对可以减少bug
被依赖者只暴露该暴露的属性还有方法呢
把风险被降低绝对不可能是假的
复制代码

试听请点击这里

闲来无事听听曲,知识已填脑中去;

学习复习新方式,头戴耳机不小觑。

番茄课堂,学习也要酷。


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

软件测试经验与教训

软件测试经验与教训

Cem Kaner、James Bach、Bret Pettichord / 机械工业出版社 / 2004-1 / 35.00

本书汇总了293条来自软件测试界顶尖专家的经验与建议,阐述了如何做好测试工作、如何管理测试,以及如何澄清有关软件测试的常见误解,读者可直接将这些建议用于自己的测试项目工作中。这些经验中的每一条都是与软件测试有关的一个观点,观点后面是针对运用该测试经验的方法、时机和原因的解释或例子。 本书还提供了有关如何将本书提供的经验有选择性地运用到读者实际项目环境中的建议,在所有关键问题上所积累的经验,以......一起来看看 《软件测试经验与教训》 这本书的介绍吧!

在线进制转换器
在线进制转换器

各进制数互转换器

HEX HSV 转换工具
HEX HSV 转换工具

HEX HSV 互换工具

HSV CMYK 转换工具
HSV CMYK 转换工具

HSV CMYK互换工具