Essence Object

http://jerry.cs.uiuc.edu/~plop/plop98/final_submissions/P10.pdf

Some objects are complicated to build; they can be built by constructing a blank object and then calling setters on it. The problem with this is that it allows incomplete instances to exist. So, separate out the tasks of assembling the parts and creating the object; create an EssenceObject by starting with a blank and calling setters, then use the EssenceObject to create the end result object in a single step.

Can we use factory classes as essence objects, and do every thing we are doing now with essence object inside the factory class? -- SeshKumar

EssenceObject clearly has a relationship to factory classes. The calling of a 'createTarget' method on the EssenceObject by the client leads to the conclusion that the EssenceObject is a kind of factory. There is nothing in the pattern which prevents a single EssenceObject being used to create multiple target objects.

I should have discussed this in the pattern. I suspect that one of the reasons I didn't was that the 'Related Patterns' heading tends to imply references to individual named patterns whereas 'factory' refers to a whole group of patterns with a similar motivation, and none of the specific factory patterns I looked at was an exact fit.

If the pattern was being written today, it would also refer to ValueObject, which is sometimes used in a creational context but with a different motivation (i.e. reduction of network round trips during creation, read and modification of a distributed object).

-- AndyCarlson

What if the essence itself is dynamic... how can we change the implementation of the essence object? That is, what if we need two sets of optional and required parameters - do we need two essence objects and doesn't this effect the created object since its signature may change depending on the essence? I think we may have to use some form of locking inside the created object. This locking mechanism should hold all the parameters that cannot be changed after object creation. -- SeshKumar

The pattern as written is of some help - the 'set' methods would be a superset of all of the possibilities and the client is free to pick which combination is called. It is the job of the validation method to figure out whether the combination of properties supplied constitutes a valid object. This doesn't address Sesh's concern about 'dynamic immutability' - this might need a more complex pattern but I think I need a concrete example of the problem in order to get my head around it properly. -- AndyCarlson

Here is an example: We have different models of the same product line. For example, take our storage units that we make; there are two models - let's call them "m1" and "m2". Each product model can have different attributes like the total number of channel cards you want on the storage model. Model "m1" comes with 3 cards and can be expanded to 6 cards, but model "m2" comes with 5 cards and you cannot change this. So the total cards on the storage unit changes depending on the model, and for some models this is immutable but for some models it is not. Had I had a way to change the immutability at the creation of the model, I would have created "m1" with mutable channel cards and "m2" with immutable channel cards. -- Sesh

I think this comes down to a question of how you want your storage unit class/classes to look - do you want to use the features of your chosen language to document and enforce immutability (in which case you will probably be using multiple single storage unit classes) or would enforcement via logic within the object be better (e.g. give you more flexibility to have new types of storage unit later without code changes?). Once you settle on your choice of design for the object or objects being created, then you can choose an existing pattern to create them, or mix and match from (say) abstract factory, builder and essence. --AndyCarlson

CategoryPattern