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


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.

closed as unclear what you're asking by BЈовић, user40980, GlenH7, amon, gnat Dec 15 '14 at 14:39

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 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 – gnat Nov 26 '14 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. – humanityANDpeace Nov 26 '14 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. – James Anderson Nov 26 '14 at 9:56

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();
            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">

    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" />

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

  • 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? – humanityANDpeace Nov 26 '14 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. – Ivaylo Slavov Nov 26 '14 at 8:23

Not the answer you're looking for? Browse other questions tagged or ask your own question.