I made pretty decent progress on the Better Money project that I started yesterday. Shown below is the class diagram for the MoneyManager library.
I tried to make the MoneyManager library as generic as possible so that accounts can be pulled from any source, not just Wesabe. For the Wesabe, I wrote the implementation and is currently having only the root methods - just enough to get started.
The GUI would interface with the library through the MoneySource class, which is incomplete as of now. It has a Manager property which holds instance of the current MoneySourceManager. One such MoneySourceManager is the WesabeMoneySourceManager. MoneySourceManager is the interface IMoneySourceManager. The way MoneySourceManager fetches the Models is upto the implementation class. The WesabeMoneySourceManager makes use of WesabeClient, the REST API client to the Wesabe API as well as WesabeFactory which derives from MoneySourceFactoryBase. My idea is that any MoneySourceFactory that contains methods to build the models should inherit from MoneySourceFactoryBase. Right now, it is rather strange kind of inheritance but I plan to improve it with time. (WesabeFactory inherits from MoneySourceFactoryBase<XDocument,XElement> and GetTags() uses XElement while GetAccounts() uses XDocument. I know it is not great, but I promise to improve it.)
The maintainability code metric for the whole library is around 88, which I think is not great. I need to refactor the code to improve this.
The MoneySource class right now has only one manager, but more Managers could be added to the class. A MoneySourceManager has to derive from IMoneySourceManager. For example,
1: public class ExcelMoneySourceManager : IMoneySourceManager
2: {
3: private MoneySourceFactoryBase<object,object> Factory;
4: private InterfaceClient client;
5: //Assumption: InterfaceClient would provide interface methods with the Excel sheet.
6:
7: //Methods to be implemented....
8: }
I should improvise the structure and the design of the library. The next step would be to get hold of a good design patterns book and identify cases for improvements. Now that I know how the current design is, I would be able to identify the applicable patterns easily. This helps me grow as an architect.
By the way, I have not implemented the WesabeFactory to use XmlSerialization. Instead I used XLinq to identify the elements for reasons - did not want to spend time on matching the serialization attributes to the Wesabe XML returned and XmlSerialization is slow. The WesabeFactory speeds up quiet a few things by using Threadpool wherever applicable. More on the api later..
No comments:
Post a Comment