views:

75

answers:

3

What I'm looking right now is a set of classes derived from a common base class. Most, but not all, of the classes require some input parameters which are obtained through modal dialogs. Those dialogs are set up and executed in the constructor of the classes. As long as the dialog isn't finished, the object isn't constructed completely. What problems could arise by delaying the execution of a constructor?

I was thinking of replacing everything with a callback mechanism that is provided to the dialogs to set up the objects or using a factory to get usable objects right after construction. What other patterns are there to solve this situation?

+3  A: 

No "problems" can arise as far as the language is concerned. The constructor is allowed to take as long as it likes.

Where it might be a problem is in the confusion it might cause. Will the programmer using the class be aware that the constructor blocks the thread for a long time?

Without knowing any details of your code, a callback or some other asynchronous mechanism might be better, to avoid blocking the thread.

jalf
+4  A: 

What do these classes do? If they are not there just to manage the UI, you have a problem with separation of concerns... the user input gathering should be separated from classes that process that input.

Eric J.
+1  A: 

I think it's a valid design choice. It does make sense to have a class called "UserInput" that will but be fully constructed after the user has provided input.

It also does induce a tight coupling to the data-entry method - interactive: you won't be able to use these classes with mockup data, for example.

So if you need the flexibility of the choice, do decouple data entry from business logic. If you want ready-to-use objects, go ahead asking the user for input at construction time.

xtofl