Design patterns 煮汤模式

所以我提出了一个模式，因为模式，根据定义，是每个人反复提出的东西，我有一种感觉，这个模式一定已经有了名字。只是我不知道如何用谷歌搜索它，过去也从未在网上读过。所以有人能认出这个并给它起个名字吗

我叫它煮汤。它是一个基本上有两种方法的类：

• 添加（某物1，某物2，…）
• 库克

add（）就像是把配料扔进锅里，cook（）就像是要求最后的结果。我使用它动态构建一个结构（一个对象树）并用数据填充它。例如，当从SQL

ResultSet

构建对象层次结构时，我只需将行数据输入到soup中，然后对其进行cook（）操作，以获取使用该数据构建的一些对象的集合

在我的实际实现中，我使用了两种不同的add（）方法，因为有时并非所有成分都可用，尽管结果基本相同

我使用相同的soup实现使用不同的数据源（如JSON）构建另一个对象树

因此，我想你可以从另一个角度来看这件事，并称之为“具有可互换数据源的对象层次结构生成器”

---

它不是一个

构建器
，因为构建器通常有明确定义的方法，可以向流程中添加特定的部分。使用生成器通常意味着理解底层结构。但在这里，我只是向它扔了很多东西，而不必知道我实际上在做什么；dr：根据您上面的描述，如果您调用
add
，一旦它是一个一次性工厂。如果您多次调用
add
，那么它就是一个混乱的生成器。不管是哪种方式，你可能会更好地使用久经考验的真品，而不是你的
汤

首先，让我重申一下我（认为我）对您潜在的新模式的理解。您创建了一个对象，
Soup
。然后在“成分”（参数）列表中添加
。最后，您将
cook
汤，它将根据您添加的参数返回某个对象的新实例

很抱歉，我是坏消息的传递者，如果我曲解了这一点，请纠正我，但从上面看，我认为这实际上是一种反模式。它有两种非常相似的模式，似乎它结合了这两种模式中最差的一种

首先是一个工厂，甚至是一个基本的构造器。我只是没有看到通过调用
add（…）
添加任何值，而
newwhatever（…）
或
WhateverFactory.getNewWhatever（…）
无法实现这些值

它非常接近的第二个模式是构建器模式，您在问题中已经承认了这一点。你似乎意识到了这些相似之处，所以我就不赘述了。然而，我确实想提及构建器模式背后的动机及其缺点。创建此模式是为了使对象能够向其使用者提供更清晰的创建界面。Wikipedia将其称为，类的构造函数列表变得不连贯地长。这样做的好处是可以获得更干净的界面。缺点之一是，您必须在实际创建对象之前存储对象的状态，这在线程安全上下文中意味着，对于您想要的每个对象，您至少要创建2个：一个生成器和一个所需对象。另一个经常被忽视的缺点是，它打破了用户的期望-他们想要
新的东西
，因为这就是语言中其他东西的工作方式。您已经打破了这种模式，根据您的文档有多好（以及您的用户对阅读文档有多关心），他们可能需要花费一些宝贵的时间来弄清这一事实

我之所以提到这些，是因为您的
汤
似乎同时存在这两个缺点。每次你想创建一个新对象时，你都需要一罐新的
汤
，它会增加另一层抽象来获得一个对象。同时，它似乎没有简化接口以获得新对象；您仍然必须向构造函数或工厂传递与通常完全相同的参数列表

我本想说一个双关语，但我想不出一个。所以我只想说你应该停止这样做

如果你不同意我上面所说的，请评论关于它的用法的任何误解或被忽略的价值，我会很高兴与你联系。
这不是一种模式，至少是一种常见的模式，我确信它没有一个已知的名称。也许你可以做
烹饪（something）
你使用
添加（resultSet）吗
或者您是选择单个属性并单独添加它们？例如
添加（col1、col2、col3等）
。