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.