Refactor AND keep original code

[Steve]

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.


--
Regards,
Steve

"...which means he created the heaven and the earth... in the DARK! How good
is that?"

[Oliver Wong]

"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

[Steve]

On 8/12/05 18:54, in article Tj%lf.196670$Io.3775@clgrps13, "Oliver Wong"
<owong@castortech.com> wrote:

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

I like the idea of a 'deprecated' warning. I might even go so far as to
generate an *error*, and force the legacy applications to define a macro or
something to override it.

Thanks very much.

--
Regards,
Steve

"...which means he created the heaven and the earth... in the DARK! How good
is that?"

[rajdep]

thanks you for your post, you help is appreciated