Making soup
So, I came up with a pattern, and since models, by definition, things happen over and over again, I have a feeling that it should already have a name. It's just that I'm not sure how to do this and have never read about it online in the past. So ... can anyone recognize this and put a name on it?
I call this making soup. This is a class that essentially has two methods:
- add (something1, something2, ...)
- cook()
add () is like throwing ingredients into a pot, and cook () is like asking for the final result. I use it to dynamically build a structure (object tree) and populate it with data. For example, when building a hierarchy of objects from SQL, ResultSet
I just pass string data to soup and then cook () to get a collection of some objects that were built using that data.
In my actual implementation, I use two different add () methods because sometimes not all ingredients are available, although the result is largely the same.
I am using the same soup implementation to create a different object tree using a different data source like from JSON.
So, I think you could look at this thing from a different perspective and call it Pluggable Object Hierarchy Constructor.
This is not Builder
because collectors usually have well-defined methods that add specific parts to the process. Using a builder usually means understanding the underlying structure. But here I am just throwing a lot of things, but I don't know anything about what I am actually doing.
source to share
Tl; dr: As per your description above, if you call add
once, the one-time Factory. If you call add
more than once, then it's a confusing Builder. Either way, you will probably be better off with the proven one, not yours Soup
.
Let me start by repeating what I (think I) understand about your potentially new template. You have an object Soup
that you are creating. Then you are add
in the list of "ingredients" (arguments). Finally, you are cook
soup, and it returns you a new instance of some object based on the arguments to add
ed.
I apologize for being the bearer of bad news and please correct me if I misrepresented this, but from the above I think this is actually an anti-pattern. There are two templates that it looks a lot like, and it seems like it combines the worst of both.
The first is Factory or even a basic constructor. I just don't see the value being added by a call add(...)
that cannot be reached with new Whatever(...)
or WhateverFactory.getNewWhatever(...)
.
The second pattern that is very close, which you confirmed in the question, is the Builder pattern. You seem to be aware of the similarities, so I will not attack them. However, I want to mention the motivation of the Builder pattern and its disadvantages. This template was designed so that objects can provide a cleaner interface to the user. Wikipedia refers to it as a telescope constructor design.where the list of class constructors becomes incoherently long. The advantage is that you get a cleaner interface. One drawback is that you must persist the state of your object before it is created, which in thread safe contexts means that for every object you want, you create at least 2: one builder and one desired object. Another often overlooked flaw is that it interrupts the expectations of your users - they want new Whatever
, because that's all that works in that language. You've broken this pattern, and depending on how good your documentation is (and how much your users care about reading it), they may have to spend some valuable time figuring out this fact.
I mention this since it seems that yours Soup
suffers from both of these shortcomings. You need a new bank Soup
every time you want to create a new object and add another layer of abstraction to get the object. At the same time, it does not simplify the interface for getting a new object; you will still have to pass the same argument list that you would normally use for a constructor, or Factory.
I was going to try and make a pun, but I can't think of it. So I'll just say that you will probably stop doing this.
If you disagree with what I said above, please comment on any misconceptions about the usage or overlooked value it provides and I will be happy to come back to you.
source to share