|
Re: Refactor AND keep original code
"Steve" <root@127.0.0.1> wrote in message
news:BFBCFA0A.117F9C%root@127.0.0.1...
> Hi,
>
> Anyone got any tips on the best to approach this?
>
> I have a C++ class that is in desperate need of refactoring. It's used in
> encoding and decoding data files and the refactoring would involve
> changing
> the data file format.
>
> However, doing this will more than likely break existing applications.
> These applications have been around for a while and while bug fix releases
> are rolled out occasionally, the application has a fair few data files
> that
> are processed by this class and we would rather be spared the risk and
> hassle of having to convert the files to the new format. (Plus, our
> customer
> isn't that keen, either).
>
> So the likelihood is we will have to keep the original class to maintain
> our
> existing apps, and create a new refactored class to exist in parallel.
>
> The question is - how would one go about naming these classes? Assume the
> class is called DataProcessor.
>
> Option 1 - keep the original as DataProcessor, and call the new one
> DataProcessor2. At least the existing app wont have to change, and
> developers on new apps can be taught to use DataProcessor2, impressing on
> them that DataProcessor shouldn't used for new apps.
>
> Option 2 - rename the original as DataProcessor1 and name the new one
> DataProcessor. Existing app will change, but the compiler can easily catch
> the name change. Developers on new apps donšt have to concern themselves
> with version numbers, since DataProcessor will always be the best class to
> use.
>
> Is this versioning of the class name a common practice? What about
> putting
> older versions of the class in another namespace?
>
> I thought there may be some kind of refactoring pattern here?
>
> Thanks for any tips.
Because the changes will break existing applications, use option 1.
Developers like the idea of "it'll always be using the latest version"
except when the latest version mysteriously breaks their code. In addition
to option 1, if you can, mark the original DataProcessor in such a way so as
to trigger a warning in the compiler. E.g. "Warning: This class is
deprecated. Please use DataProcessor2 from now on."
- Oliver
|