Remaining nimble in the face of evolution

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

   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
   considerable legacy code based on this assumption (and many classes
   extended this base "archivable").  Starting to sound familiar?

Now a reality check occurs and the requirement evolves such that the
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
behavior (i.e., archive=yes).  This approach "feels" wrong.  There are
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
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
managing evolution?

Thanks in advance for your comments.

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

More information about the Python-list mailing list