16 Dec 2006
Reading through William Horn's blog, I feel that I should post some comments about the OpenAI project that didn't really belong in the architecture document.
I was tempted in several places in my document to insert critical remarks about how things were structured (or not structured).
After going through some of the initial steps recommended for reverse-engineering (read the code in one hour, skim the documentation, run the application), it was clear that this application had a couple of very large packages that should be split into smaller packages. The original developers did acknowledge a desire to separate the GUI from the application, but that is really an understatement.
The GUI package in this applicaiton is quite large and complex, and includes several application-related subordinate packages. A couple of other packages are huge as well, and one Class contains 80 member functions. Different domains have different rules-of-thumb. I worked at a motorcycle shop in 1980 that had a rule-of-thumb "if it works, run it." That worked well in the motorcycle repair domain, and I suppose a working software system is good, too, but I think the rule-of-thumb for class sizes is that they should be somewhat smaller than 80 member functions to allow for easier maintenance and modification (I remember that we should start looking at the Class with a critical eye when we get more than 10 member functions or so in a Class--it's not always feasible to set a hard limit).
All in all, though, it's always good to look at how other people write software, and it's great to look at how they do so with a critical eye. It's less painful to learn from others' mistakes (one of my rules-of-thumb).
I was tempted in several places in my document to insert critical remarks about how things were structured (or not structured).
After going through some of the initial steps recommended for reverse-engineering (read the code in one hour, skim the documentation, run the application), it was clear that this application had a couple of very large packages that should be split into smaller packages. The original developers did acknowledge a desire to separate the GUI from the application, but that is really an understatement.
The GUI package in this applicaiton is quite large and complex, and includes several application-related subordinate packages. A couple of other packages are huge as well, and one Class contains 80 member functions. Different domains have different rules-of-thumb. I worked at a motorcycle shop in 1980 that had a rule-of-thumb "if it works, run it." That worked well in the motorcycle repair domain, and I suppose a working software system is good, too, but I think the rule-of-thumb for class sizes is that they should be somewhat smaller than 80 member functions to allow for easier maintenance and modification (I remember that we should start looking at the Class with a critical eye when we get more than 10 member functions or so in a Class--it's not always feasible to set a hard limit).
All in all, though, it's always good to look at how other people write software, and it's great to look at how they do so with a critical eye. It's less painful to learn from others' mistakes (one of my rules-of-thumb).
