Posts from December 2004.

Been Doing A Bit Of Housekeeping

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 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!

Brent Simmons gave me a sleepless night.

I had a really sleepless night last night, and it’s all down to Brent Simmons’ Black Box Parsing post on his weblog.

Why am I blaming him? Because it finally brought to the fore that I really need to clean up my code and make it far more object orientated (OO), something that has been nagging me for quite some time.

I’m afraid I’m a bit of a perfectionist, and this is probably one of my biggest sources of procrastination, something I realised just recently when listening to The Procrastinator’s Handbook: Mastering the Art of Doing It Now. Wanting to do something perfectly, is most definitely the reason I procrastinate the most, the idea of not getting something done to a high standard creates a lot of fear in me, and can stop me in my tracks.

However, I’ve already developed some of my application in a way which is congruous with OO development, and each time I add a new feature or need to modify a bit of code, I improve it a little and usually move it towards better using the OO features of RealBasic, probably because I’m learning so much more each time I sit down and start developing. I’m now at a point though that I really need to clean up a core part of my project, there are some new features I want to implement and can not do cleanly and efficiently with the current layout and communication between the data model, gui objects and controlling functions (see what I did there, Model-View-Controller :-) ).

What’s really bad is that I’ve been fully aware of the benefits of the Model-View-Controller (MVC) pattern for a year or two, since I first started looking at development on my Mac. Objective-C is a great OO development platform, and I’ve played with it and run through a number of tutorials and created a few play apps using the great free IDE called XCode on OS X, usually using the MVC pattern. So, why is it I didn’t use MVC properly from the outset when I started doing some serious development? Who knows, maybe I’m just lazy, or maybe I’m not lazy enough to use the productivity gains when OO is used to its full potential. Or maybe, I just got carried away and fell into the trap of whipping up a quick prototype, but not enforcing the fact that it really was a prototype and that it should be thrown away and developed afresh correctly with longevity in mind. Mind you, there are some people that believe a prototype should never be thrown away, that it should simply be improved upon and brought up to scratch rather than writing off the investment in it. I think I may go down the hybrid route; I can easily save elements of my project as classes, and even enforce this in my mind by making them external classes that can be picked up by other projects if I wish. This will help me get started in shifting the code around to get rid of some of the dependencies I built in between the model and view, and allow me to work on parts individually and swap in improved objects as necessary. That’s where the Black Box approach really comes in handy.

So, I’ve decided that next week will be an architecture design week, I will sit down and design the architecture of my app properly, making sure to keep the model, view and controllers separate, and to ensure that I allow the application to use different models without changing anything in the view, and only adding one hook in one of the controllers. I want to make my app able to switch between different database schemas with so much ease that I can quickly and easily add new models as new databases come to market in the area I’m targeting.

Should be fun, and once I’m happy with my design I may start sleeping properly again, until the next big idea hits that is!