July 25, 2010 Design Patterns
July 25, 2010 Design Patterns
Imagine that your application is very complicated and it happened that you use two logging providers – one is Log4J and another is Java Logging. Your co-worker got great idea to have specification of which of the providers to use in configuration file. As you wrap all logging logic behind some ILogger interface, you also want to hide exact logging provider from client code and pass creating logic to some separate class.
For me this design patter is the most familiar and easiest. I’m sure that most of the readers have seen it many times. So the intent of the Factory Method is to hide exact class that should be created basing on some conditions.
In our example classes that should be created are Log4J or JavaLogging, they both implement interface ILogger, that is widely used in your application.
As you already guess it might be that in future you will decide to use another logging provider. As we already described in our scenario we read which logging provider to use from some configuration. For not exposing exact classes we delegate this work to LoggerProviderFactory. Here is usage:
ILogger logger = LoggerProviderFactory.GetLoggingProvider(providerType);
logger.LogToConsole(“Hello Factory Method Design Pattern.”);
}
private LoggerProviderFactory.LoggingProviders getTypeOfLoggingProviderFromConfigFile() {
return LoggerProviderFactory.LoggingProviders.Log4J;
}
What we are getting back from GetLoggingProvider method is interface. Factory Method decides which of the concretes return basing on the input parameter, which in our case is enum.
Here is implementation of Factory Method:
public enum LoggingProviders{
JavaLogging,
Log4J
}
// this is our factory method…
public static ILogger GetLoggingProvider(LoggingProviders logProviders)
{
switch(logProviders){
case JavaLogging:
return new JavaLogging();
case Log4J:
return new Log4J();
default:
return new JavaLogging();
}
}
}
Because my hardcoded configuration logic returns me Log4J and since implementation of LogToConsole of Log4J concrete logger looks like:
I’m getting this as output: Log4J: Hello Factory Method Design Pattern.
Here is my drawing try:
If you liked or disliked this blog post, just let me know.
Check out my Design Patterns Table.
Markdown | Result |
---|---|
*text* | text |
**text** | text |
***text*** | text |
`code` | code |
~~~ more code ~~~~ |
more code |
[Link](https://www.example.com) | Link |
* Listitem |
|
> Quote | Quote |
I found interesting methods for logger such as LogToDataBase, LogToConsole etc…
do you use the same approach in production applications? I mean do you specify right in the code where you want to log message?
I'm using NLog (for .NET) that gives me a very flexible way to control what and where is written without user code knowing that.
I find this very good practice so I wonder if you really use such logging structure at work?
Nope, we are not using such of course…
Where to log is configured to *.config files.
Hm, might be that I better use something like "LogError, LogMessage, LogDebug" insted… you are forcing me to edit this article.
Yeap, I think it'd be definitely better! Although I don't know if it is good or bad (from your point of view) to edit your post :)
It is bad to edit without notifying readers about this. I should always be honest with readers…
That is why if I will edit it I will definitely emphasize on that fact.
At least if someone will have some doubts as you have he/she can take a look at comments :)