【问题标题】:Using a builder pattern when concrete implementations have different possible properties当具体实现具有不同的可能属性时使用构建器模式
【发布时间】:2021-10-14 21:20:35
【问题描述】:

我目前正在为用于 2 种预订类型的预订系统设计域。

这两种类型都有共同的属性,例如它们的日期和位置。但是,两者都具有对方没有的属性。这里的例子是您可以带客人一起来的一种类型,而不是另一种;或者您可以要求一种类型的午餐,而不是另一种类型的午餐。

目前我有一个抽象的 Reservation 类,每种保留类型都有一个具体的实现。然后我有一个 ReservationBuilder,它在其构造函数中将枚举(保留类型)作为参数。然后,此构建器将包含两种保留类型的方法,并且为无法使用信息的保留类型使用方法将在构建时不执行任何操作,或引发错误。

不过,有些事情告诉我,这不是对这种模式的良好使用。将构建器也抽象出来会更好吗?还是工厂模式更适合我的用例?

【问题讨论】:

    标签: oop design-patterns


    【解决方案1】:

    您已经确定了对抽象超类Reservation 的需求。您还确定了对子类的专业化需求,例如GroupReservationRoomServiceReservation

    使用构建器或工厂模式的动机是什么?如果问题是在给定字符串的情况下创建一个类的新实例,一些if 语句或case 语句就可以正常工作。

    if(userSelection.equals("group")) {
        return new GroupReservation();
    }
    

    如果动机是为了更复杂的东西,构建器或工厂类可能会很有用。选择和实例化具体类的杂乱细节可以这样隐藏。

    面向对象的程序员可能会在不知不觉中戴上“模式护目镜”。当我们戴上图案护目镜时,我们会接近每一个设计选择,寻找合适的图案来实现。有时我们可以使用一种语言特性来消除对模式的需求。有时if 声明就足够了。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2017-03-22
      • 2021-05-26
      相关资源
      最近更新 更多