lmi
[Top][All Lists]
Advanced

[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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]