in reply to Re: package namespaces
in thread package namespaces

Because I would like to generalize the solution across all of the modules that I call "system" modules. The group of modules make up an application or toolkit that I would like to be able to customize on a per client basis while maintaining the core code base. Therefore, also on a per client basis, I would like to be able to subclass any of the system's modules without rewriting them each time. This means that whatever I do to make Foo subclass-able, I need to also do to Bar.

Replies are listed 'Best First'.
Re: Re: Re: package namespaces
by perrin (Chancellor) on Jun 05, 2002 at 03:28 UTC
    The point of all this OO stuff is better abstraction. If you are always calling Bar with methods (either class methods or object methods) you can completely change the implementation of Bar at any time. You can make it subclass from System::Bar, or Quux, or System::Quux, or all of them at once. All that matters is that you keep the public interface for Bar the same. You will never need to change code that calls methods on Bar unless you change the interface of Bar.
      Precisely. 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. 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. Now managing the factory hasn't been discussed but would require a registration process to indicate which implementation to use.
        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.