Journal GeckoFood's Journal: [geek] Rebuilding a hybrid application 2
I have an application I wrote a couple of years ago that I have modified and messed with as time has permitted. With a new release of wxWidgets and a new release of Embarcadero C++ (formerly CodeGear, formerly Borland) I broke out the application for an update and the compile died a horrible death. Too many things have progressed between the updates, especially related to wxWidgets, so it is time to rethink the design.
This is actually a good thing. I have been unhappy with the underlying code for several reasons. It started as a hack that turned into a pseudo-designed application with an underlying class structure that worked, though it was a little tricky to maintain because of its original code design.
I call this a "hybrid" application because it is an indiscriminate mix of C and C++ code and design, some of the cross-mix very deliberate but a lot of it not so much. For example, one class handles reading files, yet uses traditional C library functions for handling said files (fopen, fclose, etc.). This will not change, as the stream libraries are slow and inefficient, even though they are mindless to use and have some safety features built in. More subtle, though, is the use of character arrays instead of string objects, which adds a lot of maintenance overhead when something doesn't quite work right.
All that is minor, compared to a more serious issue. I did not do a good job of keeping workhorse code and GUI code separate. That is, porting the application to use a different GUI would take a bit of work, as the class would need appreciable code changes to support the new library.
In a nutshell, this application as it stands right now is a hacker's delight.
I have started the redesign. The classes comprising the system are being more streamlined and tasks within the overall system are being redistributed. There will be a module that handles only the interface between the base libraries and the GUI. The code will stick very strictly to C++ except in the area of file handling, which is a performance decision.
In the end, I do not expect the application to be appreciably different on the surface, at least in the short term. The end result of this will be a better designed, more easily maintained application that can be expanded with a lot less effort and pain. It will finally be done *right* as opposed to being done "sufficient enough to work".
Design Patterns (Score:1)
I'd recommend Head First Design Patterns if you don't do development regularly (you're and IT guy more than software guy aren't you?). It's a great book and easy read. Design patterns in general really help organize thoughts and design better code.
Re: (Score:2)
I'd recommend Head First Design Patterns if you don't do development regularly (you're and IT guy more than software guy aren't you?). It's a great book and easy read. Design patterns in general really help organize thoughts and design better code.
I have that book. I pick it up and dig through periodically.
I am more or less a jack-of-all-trades anymore. I was a software developer by profession until about 3 years ago when I made a switch to system administration and OS development. That said, I still keep my toes wet with development in case I decide to go back.
My application got the way it is when I cobbled it together quickly in a weekend, then started piling on more code. I should have gone back in the early stages and done the design work then, t