Remaining nimble in the face of evolution
jim.vickroy at noaa.gov
Mon Feb 4 17:45:51 CET 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
class (having the same name but necessarily in a different module) that
not provide the archive capability. The desired module could be
response to some start-up parameter.
What are pitfalls of the above approaches and what are other strategies
Thanks in advance for your comments.
... I'm not dead yet (hopefully) !
More information about the Python-list