|
The project I work on has seen two major iterations and currently suffering through it's third. The baseline written in the early 90s, the second iteration written in the late 90s, and the current iteration being worked on for the past 5 years. The baseline portion appears as if it was organized to minimize the number of header/source files. This means headers contain multiple declarations and defines, and source files are tens of thousands of lines. Everything is global and structs are used for organization. Executables require a majority of the project dynamic libraries be linked due to pervasiveness of libraries dependent upon libraries dependent upon libraries. The second iteration added functionality directly on top of the legacy capability. On the bright side, all the new code was written using "OOP". Classes make use of proper data encapsulation and source files are broken out accordingly. However, instead of separate classes to separate responsibilities and promote encapsulation, there are simply high level classes that handle a vast array of capability. To manage these beasts, the class method definitions are organized by similar functionality and put into a source file named so as to classify that functionality. (Kudos for at least naming the files appropriately!) With this design, all the classes are massive and all-inclusive with no interface(s). How do the monster classes interface with each other you ask? Make everyone a friend class of everyone else! This way, the private data is just available without the need for a proper interface. Problem solved. In the third iteration, my team and I have done our best to re-factor and improve. However, due to the size of the code base, schedule constraints and contract scope not everything can be fixed at once. Everything in due time.
|
#
?
Aug 17, 2014 19:18
|
|
|
|
| # ? May 21, 2024 09:29 |
|
|
I am a poo poo bag and did not mean for this to be a new thread. I meant it as a reply in Coding Horrors.
|
|
#
?
Aug 17, 2014 19:20
|
|