Tuesday, 7 May 2013
Since I'm not doing any topics anymore it's funny to think about the first couple of sentences. It's a nice bla bla without any effort to drive you from the teaser to the real post.
It could also be a nice trick, not to reveal an importent content inside. Anyways. So yeah, I started refactoring the chart generation classes in StatDiary. I was drawing a lot and was trying to figure out how the configurations should be populated. The problem is that the populated data has affect on the chart itself in various ways. In changes the range, the axis or maybe the labels. In the old method I was passing the whole chart object to the data providers to do whatever they want to do. It was only convenient, nothing else. Horrible design pattern. What I intend to do now is separating the responsibilities. The data gatherer subjects only need to return a special result format that the chart object can consume. The good thing is that the information coming from the data crawlers can be well defined - but still only depends on the data provider. Then when it goes to the chart it can populate its storage and set the config wherever it's necessary.
It's a small change but requires quite some code updates. The real advantage is that data providers can be as generic as possible, so we can use them to feed the xml-rpc or a rest service. Also it makes the configuration easier, since the objects effected gonna be less.
It's funny but when it comes to a code that I develop for myself I tend to go for the more efficient way, not the best quality. Maybe if it would be really successful and I'd spend all my time on it. Not yet.
The other thing I found is using pseudo code help a lot when designing architecture. In pseudo code you can see the communication and the process much better. I even risk to say that it's better than charts, however they have a different purpose. Charts are just a hassle to represent control structures. I'm more familiar to see the pseudo code and predict the outcome or validate the pattern.