Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have this existing code where they have a class and an initialization method in that class. It is expected that once the object of the class is created, they need to call initialize on it.

Reason why the initialize method exist The object gets created early to have a global scope and then the initialize method gets called later after loading a dll which it depends on.

Issue with having the initialize The class now has this bool isInitialized which needs to be checked in every method before it proceeds and returns error if it is not initialized. Simply put, it is a big pain.

One possible solution Initialize in the constructor. Have just a pointer to the object in the global scope. Create the actual object after the dll is loaded.

Issue with the above solution Anyone who creates an object of this class needs to know that it needs to be created only after the dll is loaded or else it will fail.

Is this acceptable?

share|improve this question

migrated from stackoverflow.com Apr 10 '11 at 9:36

This question came from our site for professional and enthusiast programmers.

    
I've had this same issue when creating OpenGL related objects that need to be instantiated before an OpenGL context exists, but are supposed to hold OpenGL dependent objects like calllists, textures, etc. –  JCooper Apr 10 '11 at 2:18
    
Stupid question #1: Why can't the object constructor load the DLL if it isn't already loaded? –  John R. Strohm Apr 10 '11 at 16:33
add comment

3 Answers 3

Nothing useful occurs if the DLL is not yet loaded; the object only generates an error. Is it a fatal error? How is the error handled?

Does your testing methodology ensure that this error never occurs in the finished product?

It sounds like a job for testing, not for architectural design. Don't just return an error, assert that it never happens.

Fix any clients of the class that presently catch and ignore the error to not try and cause it in the first place.

A multithreaded pattern might be to set a shared condition variable after loading the DLL, and have the object's constructor wait (and block other threads) until the DLL is loaded.

share|improve this answer
    
I think you are right, there is nothing wrong with throwing an exception upon creation of the object in question if the DLL has not be properly initialized. Client code then would only need to deal with this exception and testing should ensure that exception is appropriately handled. –  edalorzo Apr 10 '11 at 2:44
add comment

Sounds like a work for a virtual proxy.

You could create a virtual proxy containing a reference to the object in question. While the DLL is no loaded, the Proxy could offer certain default behavior to clients, once the DLL is loaded, the proxy will simply forward all requests to the real subject.

The virtual proxy will be responsible for checking the DLL initialization and based on this decides if the request should be delegated to the real subject.

Proxy Pattern in Wikipedia

How do you like this idea?

share|improve this answer
    
you dont really solve much here. for every method added in the actual object, you would need to add that method to the proxy also. No? –  Sriram Subramanian Apr 10 '11 at 2:15
    
This avoids the problem of remembering to call the init. function, but it seems like every function in the proxy still needs to check to see if the .dll is loaded. –  JCooper Apr 10 '11 at 2:15
    
@Sriram there is big difference now, using a proxy you have restricted the maintenance related to DLL checking to a single class: the proxy. The clients of the class won't even need to know about DLL checking at all. Since most methods will do delegation I do not see much of a problem in having to implement the interface in both the real subject in the proxy. In other words you can prevent creation of the real subject until you are sure the DLL has been loaded, and then you won't need to check for DLL state every time. –  edalorzo Apr 10 '11 at 2:31
    
@edalorzo: while the idea is good, the issue here is that we are already talking about a proxy, and the OP is complaining about having to check in each method of its proxy... –  Matthieu M. Apr 10 '11 at 12:08
add comment

First thing: avoid global objects as the pest, unless their state never changes (configuration).

Now, if you're stuck with it, for whatever reasons, there are several designs that could probably help you.

I came up with two ideas:

  1. Use a Facade to load the DLL. The Object may only be accessed through the Facade, the Facade loads the DLL upon creation and instantiate the Object at the same time.

  2. Use a Proxy, but the smart kind ;)

Let me elaborate on the second point, since I fear that @edalorzo's answer might have frighten you:

// Private
static Object& GetObjectImpl() { static Object O; return O; }

// Public
static Object& GetObject() {
  Object& o = GetObjectImpl();
  assert(o.isInitialized() && "Object not initialized yet!");
  return o;
}

Now you only have a single check.

This can also be done through some kind of smart pointer:

Pointer<Object> o;

Here you only reserve space for a pointer, initially null, and only when the DLL is loaded will you actually allocate the object. All previous accesses should raise an exception (NullException :p ?) or terminate the program (cleanly).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.