With the software design description (SDD) contexts in hand from the previous post here and using a deconstruction of the excellent Dr. Dobbs article "A Lightweight Logger for C++" by Janiszewski (January 31, 2013)[1] as a basis for implementation then given the following observations about that article:
- listing 1 breaks the SDD golden rule (such macro cruft should be deprecated)
- listing 1 static log_inst object defined per-translation unit results in each .cpp file then having it's own logger with it's own corresponding state - this is bad.
- Is this a rare case where a singleton makes sense as service facade?[2]
- listing 3 the log_policy_interface can be generalised to a serliazable interface[3]
- listing 5 a redundant set of magic strings (fight the war on magic strings)[4]
- listing 6, therefore, also redundant.
- listing 7 the variadic template[5] honey worth swatting the other bees to get to!
- listing 8 I think there are better ways to get a time stamp[6] and I'm not sure about automagically[7] embedding and formatting (it's what shlogger did but it is hidden activity that is not clear in the context of the code)
All of which results in the following class diagram for the logging service framework:
 |
| Lumberjack Logging Services class diagram created using Lucidchart |
References:
[1] http://www.drdobbs.com/cpp/a-lightweight-logger-for-c/240147505?pgno=1
[2] http://c2.com/cgi/wiki?SingletonsAreEvil
[3] http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html
[4] http://codebetter.com/matthewpodwysocki/2009/03/19/functional-net-lose-the-magic-strings/
[5] http://en.wikipedia.org/wiki/Variadic_template
[6] http://stackoverflow.com/questions/14504870/convert-stdchronotime-point-to-unix-timestamp
[7] http://www.urbandictionary.com/define.php?term=automagically
link
No comments:
Post a Comment