Why tightly coupled programs are a bad idea!

Today, I was working on the next release of Painter Pro, codenamed Dundee which I am releasing as version 1.3 of the application, and is next in line after St Andrews and the current build known as Aberdeen. For the Dundee build, there are some major changes. As I started work of improving the speed of algorithms used in Painter Pro, I also started to look at other ways to improve the overall performance.

Whilst I was working away, improving speed, I was working on linking code to make it efficient. I noticed that whilst I was working on this, all of my classes linked together through one library, i.e. they were all dependant on this one class library. Three libraries make up a lot of the components of my software, namely Balfour's Business Class Library (a set of business tools, methods, controls and more), Balfour's Business File Extension Library (a set of file extensions for use in the business applications) and Balfour's Business Extension Class Library (a set of tools, methods, controls and more which build upon the BBCL and is loosely coupled to it).

The class library houses all of my file extensions and nothing more (BIF, WUX, DUX, RUX, QQS and more). This is why I did not want the library to contain this code. Instead of doing this, I decided to duplicate the code (which again is not a good idea). The file extension library should be independent of all of the other libraries, or at least of the extension library. If they are linked, none of them can compile, because the changes require the latest versions of each other.

Coupling like this should be avoided, not just so that the libraries work alone but so that at least one of the libraries can function without the other. It's a very important part of writing a good library of classes.