2015-11-05, 01:38
Hello all,
As we've been discussing I'm working on an example of how we can use Dependency Injection as a software design pattern to help with removing so much of the interdependency between various components of our code base.
If you want to see the progress so far you can get a snapshot of it here: https://github.com/jimfcarroll/xbmc/tree/di
After some deliberation and discussion I decided to start with the Weather functionality. The reason is that it's already somewhat well isolated.
The story so far:
Since Weather, as everything else, relies on logging, I decided to refactor logging slightly. To be able to separate Weather into it's own independently testable component I wanted to make the static methods on CLog a thin veneer over an underlying implementation.
To do this I reversed the relationship between CLog and ILogger. Instead of an ILogger implementation in terms of CLog, I use the ILogger interface (modified as needed) behind the implementation of all of the CLog static methods. This way we can, for example, set a CLog implementation for a test context that doesn't pull the user's home directory into the picture.
The current CLog implementation relies on a platform specific file management, platform specific date time, and g_advancedSettings. I'm currently in the process of trying to resolve this.
First, the 2 platform specific classes are now two (I didn't do the windows one yet ... does anyone really use windows? :-) ) implementations of ILogger. The appropriate one is compiled into the XbmcContext ( https://github.com/jimfcarroll/xbmc/blob...ontext.cpp ).
Of course, there's now a problem with CLog use outside of the context. I have a solution for this that can be removed once everything is managed within the context.
On the date/time functionality - I moved that to C++11 chrono functionality rather than port the platform specific code.
Now there's a major interdependency problem between the command line parser, Application, g_advancedSettings, CSpecialProtocol, main and CLog that I'm trying to resolve. I need to set and get the location of the log file and the log level settings. There is an order-of-initialization problem I'm trying to resolve.
I'm going to move the command line parsing to a passive object. Right now it calls out to the various affected components (and is therefore "active") as the command line is parsed. I'm going to create a second class that parses the command line but simply retains the values. I will move the parsing of the values one at a time to this class so the two will exist until everything affected is moved over.
Then, ultimately I'll get to the weather piece.
Any comments welcome.
Jim
As we've been discussing I'm working on an example of how we can use Dependency Injection as a software design pattern to help with removing so much of the interdependency between various components of our code base.
If you want to see the progress so far you can get a snapshot of it here: https://github.com/jimfcarroll/xbmc/tree/di
After some deliberation and discussion I decided to start with the Weather functionality. The reason is that it's already somewhat well isolated.
The story so far:
Since Weather, as everything else, relies on logging, I decided to refactor logging slightly. To be able to separate Weather into it's own independently testable component I wanted to make the static methods on CLog a thin veneer over an underlying implementation.
To do this I reversed the relationship between CLog and ILogger. Instead of an ILogger implementation in terms of CLog, I use the ILogger interface (modified as needed) behind the implementation of all of the CLog static methods. This way we can, for example, set a CLog implementation for a test context that doesn't pull the user's home directory into the picture.
The current CLog implementation relies on a platform specific file management, platform specific date time, and g_advancedSettings. I'm currently in the process of trying to resolve this.
First, the 2 platform specific classes are now two (I didn't do the windows one yet ... does anyone really use windows? :-) ) implementations of ILogger. The appropriate one is compiled into the XbmcContext ( https://github.com/jimfcarroll/xbmc/blob...ontext.cpp ).
Of course, there's now a problem with CLog use outside of the context. I have a solution for this that can be removed once everything is managed within the context.
On the date/time functionality - I moved that to C++11 chrono functionality rather than port the platform specific code.
Now there's a major interdependency problem between the command line parser, Application, g_advancedSettings, CSpecialProtocol, main and CLog that I'm trying to resolve. I need to set and get the location of the log file and the log level settings. There is an order-of-initialization problem I'm trying to resolve.
I'm going to move the command line parsing to a passive object. Right now it calls out to the various affected components (and is therefore "active") as the command line is parsed. I'm going to create a second class that parses the command line but simply retains the values. I will move the parsing of the values one at a time to this class so the two will exist until everything affected is moved over.
Then, ultimately I'll get to the weather piece.
Any comments welcome.
Jim
