Java设计原则 - 迪米特法则

六大设计原则

定义

一个对象应该对其他对象保持最少的了解

迪米特法则又叫最少知道原则,只与朋友说话,不要与陌生人说话。对类而言,哪些是朋友类呢?出现在成员变量、方法的输入输出参数中的类称为成员朋友类,而出现在方法体内部的类不属于朋友类。也就是说,方法体内的局部变量最好不是陌生类。

场景

我们设计一个场景,客户的空调坏了,联系商家叫维修师傅上门维修空调:

// 工具类
public class Tool {
    public String getName() {
        return "扳手";
    }
}
// 维修师傅
public class Worker {
    public void doWork(Tool tool) {
        System.out.println("维修师傅用" + tool.getName() + "在维修空调");
    }
}
// 商家
public class Business {
    private Worker worker;
    public Business() {
        worker = new Worker();
    }
    public void command() {
        Tool tool = new Tool();
        worker.doWork(tool);
    }
}
// 客户
public class Client {
    public static void main(String[] args) {
        Business business = new Business();
        business.command();
    }
} 

我们重点分析商家类Business,它的直接朋友类是维修师傅类Worker(出现在成员变量中),可是command方法内却出现结果陌生的工具类Tool。商家类Business其实并不需要知道工具类Tool的存在,他只与维修师傅类Worker打交道就行,至于师傅用什么工具,他不care的。
所以,我们需要修改一下:

// 维修师傅
public class Worker {
    public void doWork() {
        Tool tool = new Tool();
        System.out.println("维修师傅用" + tool.getName() + "在维修空调");
    }
}
// 商家
public class Business {
    private Worker worker;
    public Business() {
        worker = new Worker();
    }
    public void command() {
        worker.doWork();
    }
}

这样修改之后,商家类Business就不再依赖工具类Tool了,因为根本不需要知道。

但是也不能和朋友类过于“亲密”,知道就好,还是延续上面的例子说明。维修空调可能需要很多工具,除了扳手,还有螺丝刀,清洁工具等。

// 工具接口
public interface Tool {
    String getName();
}
// 扳手工具类
public class BanShou implements Tool {
    return "扳手";
} 
// 螺丝刀工具类
public class LuoSiDao implements Tool {
    return "螺丝刀";
}
// 清洁工具工具类
public class QingJieTool implements Tool {
    return "清洁工具";
}
// 维修师傅
public class Worker {
    // 用扳手修空调
    public boolean doWork1() {
        BanShou tool = new BanShou();
        System.out.println("维修师傅用" + tool.getName() + "在维修空调,没修好");
        return false;
    }
    // 用螺丝刀修空调
    public boolean doWork2() {
        LuoSiDao tool = new LuoSiDao();
        System.out.println("维修师傅用" + tool.getName() + "在维修空调,没修好");
        return false;
    }
    // 用清洁工具修空调
    public boolean doWork3() {
        QingJieTool tool = new QingJieTool();
        System.out.println("维修师傅用" + tool.getName() + "在维修空调,修好了");
        return false;
    }
}
// 商家
public class Business {
    private Worker worker;
    public Business() {
        worker = new Worker();
    }
    public void command() {
        if (worker.doWork1()) {
            System.out.println("维修师傅使用扳手修好了空调");
        } else if (worker.doWork2()) {
            System.out.println("维修师傅使用螺丝刀修好了空调");
        } else if (worker.doWork3()) {
            System.out.println("维修师傅使用清洁工具修好了空调");
        } else {
            System.out.println("维修师傅修不好空调了");
        }
    }
}

例子中,商家类Business的确只与朋友类Worker说话,但是不觉得商家类Business知道管太多了吗?还要“指挥”维修师傅类Worker怎么去修。这是因为维修师傅类Worker“告诉”商家类Business太多“秘密”了,也就是公布太多方法了!既然知道原因,那就把方法私有化,自己知道就行:

// 维修师傅
public class Worker {
    // 用扳手修空调
    private boolean doWork1() {
        BanShou tool = new BanShou();
        System.out.println("维修师傅用" + tool.getName() + "在维修空调,没修好");
        return false;
    }
    // 用螺丝刀修空调
    private boolean doWork2() {
        LuoSiDao tool = new LuoSiDao();
        System.out.println("维修师傅用" + tool.getName() + "在维修空调,没修好");
        return false;
    }
    // 用清洁工具修空调
    private boolean doWork3() {
        QingJieTool tool = new QingJieTool();
        System.out.println("维修师傅用" + tool.getName() + "在维修空调,修好了");
        return false;
    }
    // 修空调
    public void doWork() {
        if (doWork1()) {
            System.out.println("维修师傅使用扳手修好了空调");
        } else if (doWork2()) {
            System.out.println("维修师傅使用螺丝刀修好了空调");
        } else if (doWork3()) {
            System.out.println("维修师傅使用清洁工具修好了空调");
        } else {
            System.out.println("维修师傅修不好空调了");
        }
    }
}
// 商家
public class Business {
    private Worker worker;
    public Business() {
        worker = new Worker();
    }
    public void command() {
        worker.doWork();
    }
}

维修师傅值提供一个方法,就是维修空调,至于怎么维修,那就是维修师傅自己的事了!这样,即使维修师傅更换维修方式,也和商家无关,商家类Business不用做任何修改!

小结

综上,最少知道原则有2个核心思想:

  1. 尽量不要和陌生类产生依赖关系;
  2. 尽量不要知道朋友类太多细节;

总得来说,迪米特法则的主要目的是减少类没必要的依赖,降低类之间的耦合度

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
1) 优秀的程序应该是这样的:阅读时,感觉很优雅;新增功能时,感觉很轻松;运行时,感觉很快速,这就需要设计模式支撑。2) 设计模式包含了大量的编程思想,讲授和真正掌握并不容易,网上的设计模式课程不少,大多讲解的比较晦涩,没有真实的应用场景和框架源码支撑,学习后,只知其形,不知其神。就会造成这样结果: 知道各种设计模式,但是不知道怎么使用到真实项目。本课程针对上述问题,有针对性的进行了升级 (1) 授课方式采用 图解+框架源码分析的方式,让课程生动有趣好理解 (2) 系统全面的讲解了设计模式,包括 设计模式七大原则、UML类图-类的六大关系、23种设计模式及其分类,比如 单例模式的8种实现方式、工厂模式的3种实现方式、适配器模式的3种实现、代理模式的3种方式、深拷贝等3) 如果你想写出规范、漂亮的程序,就花时间来学习下设计模式吧课程内容和目标本课程是使用Java来讲解设计模式,考虑到设计模式比较抽象,授课采用 图解+框架源码分析的方式1) 内容包括: 设计模式七大原则(单一职责、接口隔离、依赖倒转、里氏替换、开闭原则米特法则、合成复用)、UML类图(类的依赖、泛化和实现、类的关联、聚合和组合) 23种设计模式包括:创建型模式:单例模式(8种实现)、抽象工厂模式、原型模式、建造者模式、工厂模式。结构型模式:适配器模式(3种实现)、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式(3种实现)。行为型模式:模版方法模式、命令模式、访问者模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式(Interpreter模式)、状态模式、策略模式、职责链模式(责任链模式)2) 学习目标:通过学习,学员能掌握主流设计模式,规范编程风格,提高优化程序结构和效率的能力。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值