设计原则-迪米特原则与合成复用原则

本文介绍迪米特原则和合成复用原则,强调在软件设计中减少类之间的依赖和提高复用性的重要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

迪米特原则(Law of Demeter LoD)

迪米特原则又叫最少知道原则(Least Knowledge Principle,LKP),这里的最少知道主要是强调,调用者对传入的参数,和接受到的返回的参数很熟悉即可,不需要知道在调用过程中涉及了哪些框架设计者自己的类。

例如你使用某个JSON框架,你传入的是可能是一个对象,最多再传入了一个Class类型就可以很方便的调用这个框架的方法,接受到了的也是已经被序列化好的JSON字符串,这些都是我们熟悉的,但是如果你要我传入一个这个JSON框架自己为了开发方便而定义的类,并且让我实例化作为参数,又或者作为返回值接收,我是无从下手的。这样作为调用者来说体验不是很好,所以迪米特原则强调的是,调用者最好只是需要知道他们熟悉的东西就可以了,无需知道更多

还是举例子饭店的例子,天天去吃饭,我们最熟悉的是当然是服务员(Waiter),我们就只需要知道这一个角色就可以了,点餐和结账只需要找他就可以,着很方便。

我们点餐后,服务员自己会去找他熟悉的厨师,又或者经理去安排接下来的工作。

所以,我们对饭店只需要知道一个服务员即可,这是最少知道的体现。

public class Pop{
    public void Order(Waiter waiter,String menuList){
        waiter.getOrder(menuList);
        //我们的调用只需要传入我们熟悉的服务员,还有点完的菜单就可以,然后剩下的交给服务员
    }
}
public class Waiter{
    
    private Cook;
    public void getOrder(String menuList){
        Cook.cook(menuList);//服务员会去处理接下来事情,去找厨师还是找什么,我们都不知道
    }
}

调用的时候。

public static void main(String[] ars){
    Pop pop = new Pop();
    pop.Order(new Waiter(),"西红柿炒蛋,蛋糕,米饭");
    //等待上菜。
}

当我们调用的时候,只传入了我们所熟悉的服务员(Waiter),因为我们天天去,当然最熟悉,然后天天点这家的菜,自然对这家有什么菜也烂熟于心。

我们也最少知道这些知识,就可以吃到我们想要的东西。我们对后面做菜的厨师(Cook)并不知道也不熟悉,我们吃个饭也不用每个厨师都认识吧,这也不合逻辑。


合成复用原则(Composite/Aggregate Reuse Principle,CARP)

这个原则其实我们天天都在用,就是让你的类持有一个其他成员变量,为什么要这样的做?

我认为,这是除了使用内部类来实现多重继承的另一种方法,这个继承其实还是要打上双引号,因为这个和继承还是有更加本质的区别。

我们可以往一个类中塞入很多其他类成员来使用他们的方法,就仿佛是继承了他们,可是就继承来说,父类的细节是完全暴露给子类的,我们把他叫做白箱复用,而通过合成/复用的方法,我们对类以外的对象是无法获得实现细节,其实我们对于这个陌生的父类只是单纯调用他的方法而已,我们把它叫做黑箱复用

这个就不做代码演示了。大家平时肯定都用到,只是没有这个方面的意识而已。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值