Tuesday, March 03, 2009 10:29 PM
Sean Feldman
Pragmatic Approach – Avoid Premature Optimizations
Today, while Mike Hesse and I were working on one of the tasks, we had to implement logging capabilities. Log4Net was the component we abstracted and used to achieve the result. Though logger our code could not know ahead what class would use it, so this is what we put in place:
1: public class Logger : ILogger
2: {
3: private readonly Type logInvokerType;
4:
5: public Logger(Type logInvokerType)
6: {
7: this.logInvokerType = logInvokerType;
8: }
9:
10: public void LogError(string message)
11: {
12: var logger = LogManager.GetLogger(logInvokerType);
13: logger.Error(message);
14: }
15: }
Yes, constructor is the one that receives the type of the invoker. We are still able to resolve logger from container despite this (this is not an issue in our case).
The issue we started to look into was performance. Normally, sample code for Log4Net would have logger instance as static. Our thoughts were, well, it’s probably ‘expensive’ to instantiate logger each time we want to log an error. But we don’t know the invoker until we have the instance of the logger constructed. Chicken or egg? But then we stepped back, and thought – in the current system this error logging will be happening rarely, so why we are concerned about “premature optimization”? Pragmatic decision was – roll it out the way it is, and if we run into issues, refactor.
Thank you Mike for keeping me on the ground.
Filed under: Agile