4 replies to this topic

[denarced]

Hei all,

I've been thinking lately about certain services like logging and how to implement them. As I've heard, the classic choices are ones mentioned in the title. I'd like to get your opinions on the pros and cons of the two. Or if you have yet another solution that's even better, let's hear it. For the worse solutions on the other hand, I think there's simply too many ways to do things badly so let's not get into that :).

My take:

• Constructor arguments
  
  • Pros: the class is more reusable. I think it's more scalable
    
  • Cons: if the amount of shared things increase, the amount of constructor arguments can also increase leading to a mess.
  
  
• Singleton
  
  • Pros: The code's probably cleaner all around (not sure).
    
  • Cons: less reusable and scaling upwards can indeed cause more work a lot of the code base is already implemented with singletons, I'm guessing.

I appreciate all participation and in particular, the views different from mine.

[WingedPanther]

I think you're putting the cart before the horse. You are discussing implementation before discussing functionality.

What is your logging service supposed to do? Depending on its responsibilities, one or the other implementation may make more sense.

[denarced]

WingedPanther said:

I think you're putting the cart before the horse. You are discussing implementation before discussing functionality.

What is your logging service supposed to do? Depending on its responsibilities, one or the other implementation may make more sense.

Exactly, in which situations is the singleton better? With what kind of responsibilities is it an absolute disaster to use it?

[WingedPanther]

The singleton design pattern should be used when there should be exactly one instance of the class. This isn't very hard to implement. If you use this for your logging system, that would mean you have a single class instance that all other classes must know about and use in order to do logging.

Constructor arguments are how you pass information into a constructor of a class to tell it how to build the new instance. This isn't a design pattern in the sense that singleton is, it's an implementation mechanism. This, to me, is in no way comparable to singleton.

So I come back to the question: what are you trying to accomplish? Do you want each of your classes to be responsible for doing logging, or do you want a singleton helper class that is responsible for logging? Is there a key resource that needs to be managed (suggesting singleton)? Is there a uniform mechanism that needs to be enforced for logging that's independent of what needs to be logged? Does each class that needs information logged have (potentially) very different logging needs? Should you have a utility class Loggable that you want all classes to inherit from to handle logging operations?

Start with what your logging needs are, what flexibility is required, and how much variability is needed. You may find yourself using a combination of a singleton class that is responsible for knowing how to access and write to the log, along with a parent class Loggable that knows how to communicate with the singleton, and all classes that need to do logging just inherit from Loggable to get the access they need.

Or maybe not.

[denarced]

I wanted to use just one logger even thou all of the classes in the small system used logging. I decided to have the class highest in the hierarchy to instantiate the logger and then pass the reference around. I could've gone with singleton but then everyone would've have to import the correct class and testing would've been more difficult and I suppose reuse as well. Someone told me that this solution was more scalable as well, but for me that didn't matter.