Remaining nimble in the face of evolution

jim.vickroy jim.vickroy at noaa.gov
Mon Feb 4 11:45:51 EST 2002


Given:
   A *class* of Python objects that, among other attributes, have the
   capability to archive themselves.

   This capability was implicit and never assumed to be optional.  There
is
   considerable legacy code based on this assumption (and many classes
that
   extended this base "archivable").  Starting to sound familiar?


Now a reality check occurs and the requirement evolves such that the
archival
behavior is to be optional.

What is the "best" strategy to handle these types of evolution.

A possible solution is to retro-fit the numerous class initializers
(constructors) with an archival switch parameter that defaults to the
legacy
behavior (i.e., archive=yes).  This approach "feels" wrong.  There are
many
other behaviors in the legacy classes that will **never** change.  Using

flags to affect behavior seems messy.

Another possible solution is to provide an alternate implementation of
the base
class (having the same name but necessarily in a different module) that
does
not provide the archive capability.  The desired module could be
imported in
response to some start-up parameter.

What are pitfalls of the above approaches and what are other strategies
for
managing evolution?

Thanks in advance for your comments.

... I'm not dead yet (hopefully) !




More information about the Python-list mailing list