The problem though arises after you've implemented a system that uses an object of type Bar throughout and now you want to reimplement Bar while still maintaining the base class. In this case, you need to insert an implementation of Bar that can still access the base class without a namespace collision.
I don't see why this is a problem. As long as you don't change the interface of Bar, it makes no difference how you implement that interface. None of the client code using Bar knows anything about System::Bar, etc.
The suggestion of using a factory addresses this because the factory deals with System::Bar - a namespace that can stay unique - while providing objects that can have their namespace location be moot. That is, the factory provides an object with the Bar interface but whether it's implemented as Custom::Bar or System::Bar is irrelevant.
There's no reason that the Bar class has to implement anything at all. Calling Bar->new() could just return an instance of Custom::Bar, or Bar could simply inherit all of its methods from Custom::Bar. It's the same thing as using a factory. The only difference is that with the factory you change the name of the class to use by modifying the factory class or its configuration, while without a factory you modify the Bar class to tell it what class to return. |