0

Is there something special(i.e. a design pattern being related) to a method named create()?

Background

The case is, I often make some instances of objects (of the same class/prototype). These objects do not always already objects reflect a state in which they are complete yet. Potentially some initialization needs yet to be done to make them more completly initialized (which cannot be done in the constructor function/method) since for some reasons the information to do so might existing already. An alternative making of the objects once this information is available is made difficult since the objects already made are made available via references to other objects (even though some functionality is not yet possible because of the some missing initalization).

In order to have a way to complete the initialization of the object I would like to call a method .create([...]) on the objects which should be a way for a second step completion of some of the objects initialization.

My interest is if related to this background is if this is a legitimate/reasonable course of action (i.e. to have some objects that may have different states of readyness; which are made into a "complete" state via a method - I thought to name that .create([...]))?

Specifically I would of course like to know if there are for instance already patterns with standard method names for the described task (two-step initialization of objects) and also if the method name .create[...] chosen in worst case conflicts with some existing pattern and would confuse readers of my code.

Improve this question
3
  • 3
    you can use traditional naming from builder pattern or "invert" the design by wrapping state yet to be initialized into a future / promise - the latter will spare you from the need to invent name for delayed construction, since there won't be delay at all Commented Nov 26, 2014 at 7:55
  • @gnat good comments and suggestions (with promises) which I feel would anyway generate a challange to start implementing. At the same effort (as making promises a component and keep the code easy) I might really think of refactoring the code so that objects made are instantly fit-for-use. Commented Nov 26, 2014 at 8:20
  • "create()" sounds awkward considering the object already exists (albeit in incomplete form). "initialize()", "connect()" or "complete()" would be better choices depending on whats missing. Commented Nov 26, 2014 at 9:56

1 Answer 1

Reset to default
3

From what I have both read and experienced, it is not a good practice to have more than one single step in initialization of an object. This is not good because

  1. You need to babysit all such objects, so that the required initialization steps are completed before the objects are used
  2. You would have to expect anyone using your code to also properly babysit their objects.

You can easily see that step 1 is quite error-prone, as one might forget some of the steps, or have a hard time to track whether a certain step completed. And, of course, you should not allow the users of your code to break it easily, meaning you should spare them step 2.

However, there are known exceptions to the above preachings which have made it to the development world and became widespread and proven practices. The most important thing is to not allow programmatically for your objects to be used before being properly initialized. This would imply that you have certain encapsulation mechanisms over the initialization lifecycle. Here are possible approaches I can think of, and the respective use cases in real life:

  • Factory classes

    A factory class, (or simply a factory), is a separate class that exposes a single method (create if you wish), that is used to instantiate your working object. It must return a fully initialized and ready-to-use instance of your class, therefore all the initialization steps happen inside of that method. For instance this code (used C# as language):

    public class FooFactory { public Foo Create() { Foo foo = new Foo(); foo.configure(...); foo.init(...); foo.complete(...); return foo; } }

    This is considered a design pattern, see wikipedia article. In most cases the creation method is called Create or CreateFoo but you can choose whatever suits you.

  • Dependency Injection (DI for short)

    This requires you to get familiar with a dependency injection framework and employ it in your project. The DI framework will take care for passing completely initialized instances of your objects and some implementations support post-constructor initialization steps that are execute before the object is ready for use. This acts in a similar way to the above factory pattern, but the advantages of dependency injection. An example is the popular Spring framework (primarily addressing Java development, has also a .NET port), which allows you to specify both init and destroy methods on your class. The init method can be any method of the class you select, so you can easily fit your intention with the create method to work with that. 

    <beans ...> <bean class="com.mycompany.Foo" init-method="create"> ... </bean> </beans>

    See this short article for some reference.

    An alternative to the above approach is to rather specify a static class and method that would initialize your Foo class. For the below example, the createFoo is a static method of the FooFactory class and returns an instance of Foo.

    <beans ...> <bean class="com.mycompany.FooFactory" factory-method="com.mycompany.FooFactory.createFoo" /> </beans>

The above list is not exhausting, there are other solutions that might seem appropriate in certain scenarios.

Improve this answer
2
  • Indeed this addresses with good advice my interest if the concept was sound (i.e. a multi-step, partially only initialized objects) very nicely, thanks. Also I would think that if the nameing .create was to somewhat an extensio (outside the factory pattern mentioned) you would have addressed this issue as well, would you? Commented Nov 26, 2014 at 8:17
  • Actually, the naming is more a choice to me rather than part of the pattern. For instance, with spring (my second example), you have the ability to tell Spring which your init method is, so you can say <bean class="foo" init-method="create" /> This will invoke the create method of your foo class before it returns a foo instance to where it was requested. You can specify anything other than create as long as it is a valid method. If you need to establish the usage of create method, you can use an interface. Commented Nov 26, 2014 at 8:23

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.