什么设计更好:通用建造者或几种具体方法?

时间:2010-07-12 12:00:45

标签: java design-patterns oop api-design

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

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

我可以用两种方式设计它:

  1. 第一种方法基于构建器模式。它是普遍的(我认为)并且可以处理所有必要的案例。但对于那些使用它的人来说,这不是很方便。典型用法如下所示:

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

    messageSender.sendPersonExpenceNotification(addresses, "John Doe", company); 
    
  3. 哪一个更好?为什么? (如果重要的话,语言是Java)

    谢谢!

3 个答案:

答案 0 :(得分:2)

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

答案 1 :(得分:0)

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

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

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

相关问题

答案 2 :(得分:0)

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

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

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