哪种设计更好：通用构建器还是几种具体方法？
我需要创建电子邮件通知服务（作为更大项目的一部分）。
它将用于发送多种基于 html 模板的通知消息。
我可以通过两种方式设计它：
第一种方式是基于构建器模式。它是通用的（正如我认为的）并且可以处理所有必要的情况。但对于那些会使用它的人来说并不是很方便。典型用法如下：
messageBuilder .put("姓名", "无名氏") .put("公司", companyObj) .processPattern(模式) .send(地址，主题);第二种方法是显式实现所有情况。这意味着使用代码（如下所示）将尽可能简单，但每次需要处理任何新情况时，我们都必须修改 API（添加新方法）。
messageSender.sendPersonExpenceNotification(addresses, "John Doe", company);
哪一个更好？为什么？ （如果重要的话，语言是 Java）
谢谢！
I need to create an email-notification service (as a part of a bigger project).
It will be used to send several types of notification messages which are based on html-templates.
I can design it in two ways:
The first way is based on the builder pattern. It's universal (as I think) and can handle all necessary cases. But it's not very convenient for those who will use it. The typical usage would look like this:
messageBuilder .put("name", "John Doe") .put("company", companyObj) .processPattern(pattern) .send(addresses, subject);The second way is to implement all cases explicitly. It means that usage code (shown below) will be as simple as possible but we'll have to modify API (add new methods) every time when we need to handle any new case.
messageSender.sendPersonExpenceNotification(addresses, "John Doe", company);
Which one is better? Why? (the language is Java if it matters)
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为答案是两者都使用。我建议在 API 中使用更通用的方法（消息生成器），然后提供易于用于特定任务的客户端便利函数/类。这样，当您添加新案例时，API 不必更新，但客户端仍然可以使用最直接的调用来执行他们想要执行的操作。
I think the answer is to use both. I would suggest using the more generic approach (the message builder) in the API and then providing client-side convenience functions/classes that are simple to use for specific tasks. This way the API doesn't have to update when you add new cases but the client can still use the most direct call for what they're trying to do.
Effective Java 第 2 版，第 2 项：在面对许多构造函数参数时考虑构建器。
构建器模式更具可读性，特别是当您可能有更多参数时。也就是说，通常更常见的是为构建器提供特定的
setName、setCompany等方法。这样您还可以强制执行类型安全，例如setSomeBoolean(boolean)、setSomeInt(int)等。构建器模式还允许您为某些参数设置默认值，用户可以方便地覆盖某些参数的默认值。提供模拟这种情况的方法涉及编写许多重载，这进一步加剧了问题。
相关问题
Effective Java 2nd Edition, Item 2: Consider a builder when faced with many constructor parameters.
The builder pattern is more readable, especially as you have potentially many more parameters. That said, it's usually more common to have specific
setName,setCompany, etc methods for a builder. That way you can also enforce type-safety, e.g.setSomeBoolean(boolean),setSomeInt(int), etc.A builder pattern also allows you to set default values to some parameters, and user can conveniently override the default on some parameters. Providing methods to simulate this involves writing many overloads, which exacerbate the problem further.
Related questions
如今，最受欢迎的设计模式依赖于“Fluent”构建器。通过这种方式，您可以获得构建器的通用性和易于理解的界面。
考虑到这只是选择方法名称的问题，实现它相当平凡。
FEST* 库 都是很好的现实示例。
Nowadays, the most favored design pattern relies upon "fluent" builder. This way, you gain the genericity of the builder, with an understandable interface.
Implementing it is rather mundane, considering it's only a matter of well choosing your method names.
Good real world examples are all the FEST* libraries.