Wednesday, July 23, 2014

Refactoring away the blues

As a developer, one of my greatest tools is the ability to refactor away and redesign an API after it was initially written. Making it more fundamentally easier to understand and use. But there is also another side of the coin that we don't touch upon quite often. Making it more flexible.

The flexibility I am touching on, is turning a singleton code base into a non singleton and initiatable. Most importantly it is designed to be embedded and self contained. So already we see that this would have huge benefits.

So what spawned me to refactor? It was quite simple really. I didn't want to finish it. I didn't want to finish my live reload program. For me this is quite concerning because it is the key component to my future development with Cmsed. And making it reloadable during runtime.

This for me is an important point to take note upon. I didn't realise while working on it, that it wasn't right. The tools weren't there from the outset design to make it possible. But majority of the code was right, just not how it was abstracted and interface designed.

Another issue, is my preference is to develop libraries and frameworks not programs. This is an interesting issue for me as I do not believe that majority of programs should be conceived as purely a tool to use. I believe they should be extended freely and interacted with, on any level the user decides. I was working on a tool that would have had a short life span, purely because it couldn't be extended easily.
While this preference can be seen as a weakness, I don't. As a weakness it means longer time to develop. But it also means a better developed program that has a higher chance of not failing. In other words, I care about quality more than quantity.

Most developers work on the basis on just getting something working that does the job. I've been there, a long time ago though. It does indeed get the job done. But its a lot more awful to look back on.
A great example of this is how PHP developers often work. Its common knowledge that a lot of PHP code is awfully written. Too much, to get the job done, not enough ahead of time thought into its design and making it robust.

Now for fun reference sake, how did I do the refactor?
Well a good part of it was a rewrite. Okay not all functionality was implemented correctly, so this isn't an issue. But I used a rather clever trick. Using D's mixin templates to implement part of a functionality within a class.

So:

interface IMy {
// methods
}

interface IService {
  void action(IMy);
}

class MyImpl : IMy {
  mixin FeatureX;
  mixin FeatureY;
}

The idea is fairly simple. Having an implementation that handles e.g. setup/destruction and properties (mostly getters). Within the implementation using mixin templates to mix in features aka sets of methods. With an interface that details all methods required.
The IService in example is just something like dmd compiler vs gdc compiler. To allow swapping out. Which may be decided the implementation at init.

The mixin templates can be in another file, allowing to hide the implementation. Or even spreading across files.

Anyway, just some thoughts.

No comments:

Post a Comment