【问题标题】:What design is better: universal builder or several concrete methods?哪种设计更好:通用构建器或几种具体方法?
【发布时间】:2011-03-14 18:51:12
【问题描述】:

我需要创建一个电子邮件通知服务(作为更大项目的一部分)。

它将用于发送基于 html 模板的几种类型的通知消息。

我可以通过两种方式来设计它:

  1. 第一种方式是基于建造者模式。它是通用的(我认为)并且可以处理所有必要的情况。但是对于那些将要使用它的人来说并不是很方便。典型用法如下所示:

    messageBuilder
       .put("name", "John Doe")
       .put("company", companyObj)
       .processPattern(pattern)
       .send(addresses, subject);
    
  2. 第二种方法是显式实现所有情况。这意味着使用代码(如下所示)将尽可能简单,但每次我们需要处理任何新案例时,我们都必须修改 API(添加新方法)。

    messageSender.sendPersonExpenceNotification(addresses, "John Doe", company); 
    

哪个更好?为什么? (如果重要的话,语言是 Java)

谢谢!

【问题讨论】:

    标签: java design-patterns oop api-design


    【解决方案1】:

    Effective Java 2nd Edition,Item 2:在面对许多构造函数参数时考虑构建器

    构建器模式更具可读性,尤其是当您可能有更多参数时。也就是说,通常更常见的是为构建器提供特定的setNamesetCompany 等方法。这样,您还可以强制执行类型安全,例如setSomeBoolean(boolean)setSomeInt(int)

    构建器模式还允许您为某些参数设置默认值,并且用户可以方便地覆盖某些参数的默认值。提供模拟这种情况的方法涉及编写许多重载,这会进一步加剧问题。

    相关问题

    【讨论】:

      【解决方案2】:

      如今,最受青睐的设计模式依赖于“fluent”构建器。通过这种方式,您可以获得构建器的通用性以及易于理解的界面。

      实现它是相当平凡的,考虑到它只是一个很好地选择你的方法名称的问题。

      真实世界中好的例子都是FEST* libraries

      【讨论】:

        【解决方案3】:

        我认为答案是两者都用。我建议在 API 中使用更通用的方法(消息生成器),然后提供易于用于特定任务的客户端便利函数/类。这样,当您添加新案例时,API 不必更新,但客户端仍然可以使用最直接的调用来完成他们尝试执行的操作。

        【讨论】:

        • 真的。我刚才也是这么想的。 +1。
        猜你喜欢
        • 2016-12-30
        • 2012-02-08
        • 2018-06-27
        • 1970-01-01
        • 1970-01-01
        • 2013-08-15
        • 2012-08-02
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多