Design Question: How to deal with initialization?

Question

Lets assume we have a class which will be widely used throughout the (c#) code, for example a Log class. Say the Log writes entries into XML files in a specific directory. Now one attempt to force the user to initialize the class with the required information would be to make the default (parameterless) constructor private and provide one which takes a logdirectory parameter. The drawback on this would be, that the user everytime something needs to be written to the log and thus an instance of the Log class is created, the parameter needs to be provided.

What other options are available? Thanks in advance for your replies.

Answer 1

I think the term you'll want to search for is the Singleton pattern. I won't fully write it out here -- it's a very google-able term. But basically you initialize a single instance of the object once as the application loads, and then throughout the application you reference that same instance

Answer 2

You're so close...implement this as a singleton, and you won't need to initialize more than once. The short answer is to create a static public instance of your class inside of itself and a public static method that either (a) initializes this instance if it's currently null, or (b) returns the already initialized instance.

There are more details to consider with the singleton pattern, but this should get you started.

Answer 3

Singleton pattern

Answer 4

Just make the Logger.Log() function a static call, and have it reference a static member that is the directory information. Then, you only have to set the directory infomration member one time, at the beginning of execution, and all subsequent calls to Logger.Log() will "just work".

Answer 5

Singleton. You can use a static class so it doesn't have to be instantiated. Then, if you have a log directory, have a default log path and a nullable parameter to the writelog method or an overridden method signature, one accepts path, one assume defaults from config file.

Answer 6

Four options (mostly covered, but not explicitly and together):

• Just make the calls static, and include static initialization. This is horrible for testing (of classes that depend on it) but very simple.

• Use a singleton as suggested by most other answers. This is potentially better from a testing point of view (you could have internal methods to replace the singleton for test purposes only), and implement an interface for mocking purposes.

• Use dependency injection: make everything that needs the dependency take it in a constructor or whatever, and get your DI framework to hook everything up. Much better from a testing perspective, but it's not exactly convenient.

• Use a factory - like the singleton, but separating the implementation from the construction. (It may effectively end up as a singleton, but without as many assumptions of that.)