[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lmi] Input unification
From: |
Greg Chicares |
Subject: |
[lmi] Input unification |
Date: |
Tue, 12 Aug 2008 15:17:56 +0000 |
User-agent: |
Thunderbird 2.0.0.16 (Windows/20080708) |
For historical reasons, lmi has always been burdened by two sets
of classes to handle input parameters--a modern set, and a legacy
set with many shortcomings--along with lots of magic glue to bind
them together. We couldn't change one without changing the other,
and changing both strained the magic glue...which was extremely
magical. Now we need to implement a complex fund-selection GUI,
and the easiest way was to get rid of this legacy code first.
That first step was consummated on 20080811T2002Z. Effects:
483 - 21 = 462 source files (4% fewer)
144576 - 7718 = 136858 source lines (5% fewer)
1083 - 97 = 986 marked defects (9% fewer)
'liblmi.dll' is now 28412716 bytes, versus 31693714 on 20080707:
ten percent smaller.
The most important benefit, though it resists quantification, is
better maintainability. Duplicated classes led to much more than
doubled complexity, as an example or two may illustrate.
Symbolic name "RetirementAge" formerly referred to
IllusInputParms::Status_RetAge
which was an alias for
InputStatus::RetAge
but the InputStatus object was held by a third class, InputParms.
Now it refers to Input::RetirementAge--there's only one name.
Symbolic name "InsuredName" in class IllusInputParms referred to
InputParms::InsdFirstName
which was notionally the concatenation of these three variables:
InputParms::InsdFirstName
InputParms::InsdMiddleName
InputParms::InsdLastName
except that the last two were always empty, having been removed
from the GUI well before the lmi epoch--yet the variables lived
on in the legacy classes, with magic glue to DTRT. Now the glue
is gone, and the symbolic name maps to Input::InsuredName.
Then there was voodoo like this function:
void InputParms::SetSolveDurations() const;
that was called during monthiversary processing on a const
instance of InputParms. Calling this const member function on a
const instance altered the values of non-mutable data members in
that class. I might remember the reason why, but nasty tricks
like this made it really hard for anyone else to maintain the
program; now a whole cohort of them is gone.
- [lmi] Input unification,
Greg Chicares <=