哪种设计更好：通用构建器或几种具体方法？

Posted 2023-02-19

【中文标题】哪种设计更好：通用构建器或几种具体方法？

【英文标题】：What design is better: universal builder or several concrete methods?

【发布时间】：2011-03-14 18:51:12

【问题描述】：

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

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

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

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

messageBuilder
   .put("name", "John Doe")
   .put("company", companyObj)
   .processPattern(pattern)
   .send(addresses, subject);

第二种方法是显式实现所有情况。这意味着使用代码（如下所示）将尽可能简单，但每次我们需要处理任何新案例时，我们都必须修改 API（添加新方法）。

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

哪个更好？为什么？ （如果重要的话，语言是 Java）

谢谢！

【参考方案1】：

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

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

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

相关问题

When would you use the Builder Pattern?

【参考方案2】：

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

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

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

【参考方案3】：

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

【讨论】：

真的。我刚才也是这么想的。 +1。