How do! It’s been a couple of weeks since my last post, in that post I said I was going to take a week to re-consider my application’s internal architecture, which I did. I’m now ready to proceed with a pretty heavy clean out of the app, moving some of the code out from gui objects into some sub-classed classes that can be re-used as and when.
Before getting stuck into my “re-design” I had a quick re-read of some of the RealBasic User Guide, which turned out to be an extremely useful thing to do. I had read a couple of posts on the NUG that discussed Interfaces that piqued my interest. Interfaces are an area of Object Orientation that had totally confused me before; I just didn’t understand what their use was. It seemed to me that they were just an inconvenience, why would you make more work for yourself by creating interface classes that didn’t actually do anything, and then have to code those interface methods in any object that “implemented” that interface? Well, it turns out that this concept of interfaces is very useful indeed (yeah, I know, why would it exist otherwise 
).
By creating some specific interface classes, and setting some objects to implement them, you can automate a lot of the relationships between objects, because of the fabbie IsA operand (in RealBasic). For example, say you have a gui object, a button say, and when pushed you want your program to go to the database and grab the latest data, and then all the other gui objects on that window should refresh to show that latest data. In normal programming you could end up writing a lot of code in that button’s action method or some other object’s method that specifically references those ListBoxes and other gui controls that need to be refreshed. Whereas if you use the concept of interfaces you can pretty much automate this refresh without any specific references to objects, which is great when you want to change the controls on your window etc. If those ListBoxes etc were actually a sub-class of ListBox, and also “implemented” a “DataConsumer” interface for example, and that interface had a function called DataAvailable, then an object that provides the new data could loop through all objects that are of type “DataConsumer” (e.g. IsA DataConsumerInterface) and call their DataAvailable methods so that they can refresh themselves. And, because the objects that implement the DataAvailable method of the DataConsumerInterface could be of pretty much any type of object, they could have very different ways of using the available data, but your DataProvider doesn’t care, it just tells the objects to do what they like with the data. This chaining of interface methods could go quite deep, here’s a noddy little example method calling chain:
Button.Action –> DataProviderInterface.GetData –> DatabaseInterface.GetData –> DataProviderInterface.DataAvailable –> DataConsumerInterface.DataAvailable
There could be many of the objects at the end of a “–>”, each getting called in turn to do whatever is required purely because they are of the right type (i.e. implement a specific Interface). This means your application gets quite loosely coupled internally, objects start providing services to others in a fairly loose knit way.
So, I’m really starting to see the benefits of Interfaces, it’s kind of a way of implementing your own Events scheme. That was week one.
Week two, I didn’t actually get around to coding any of these changes. Because I realised I needed to pull a lot of my code out into new classes, I also thought it might be prudent to change Source Control Manager (SCM) software, as CVS just wasn’t going to cut it. Why? Because I’ll no doubt be creating a number of external objects while refactoring my code, and that may including renaming them occasionally, and CVS is rubbish at that, history isn’t going to be maintained, and I would like to keep that.
So, I went on a World Wide Wander in a search of a better SCM than CVS. The obvious upgrade would of course be Subversion, and I looked long and hard at it, and didn’t like what I could see. It doesn’t matter what some people say, there are dependencies that I can’t deal with, and I’m just not quite comfortable with it’s maturity just yet, and I guess I don’t like the idea of using a database to store the code. I just have some funny feelings about SVN, so I’m staying clear for the moment.
I used c2.com and Version Control System Comparison to get a head start, whittling it down to a few candidates, including (but not restricted to) GnuArch, Monotone and Perforce.
I’ve used GnuArch before, and really liked it, but it’s a bit fiddly, and the tools are a pretty basic, I was looking for something a little more mature and with a few nice gui interfaces.
I’ve not used Monotone, and was tempted, but I’d have to build it (I’m using Mac OS X which doesn’t have a binary available), and frankly I don’t have a lot of time to go learning what seems to me to be a fairly complex application. And again, I couldn’t see any nice gui programs for it.
So, I’ve gone for Perforce, and so far, I’m totally over the moon with it. It was an absolute delight to set up, just dropped a couple of binaries in my path (/usr/local/bin) and started up the server with a couple of environment variables set to tell it where I wanted to store the data. And that was it really, the Command Line Interface (CLI) is a doddle, very straight forward to use, but also very powerful, and there is a pretty good gui app too. And to round it all off, it’s got one of the best web interfaces I’ve seen. I like the fact that the meta-data is kept separate from the actual source control, and I particularly like that the source is held in RCS files, makes it really simple to extract from if I should want to change SCM, I trust RCS. It may be a little out of my budget to buy (even though it is pretty cheap), but thankfully it’s free for two users, and there’s only one person in my company, so I’m covered!
So, this week I are be mostly getting my code into shape, honest!
