February 01, 2000
How Non-Member Functions Improve Encapsulation
Templates and Factory Functions at Namespace Scope
In the main article, I argue that static member functions should be made non-members whenever that is possible, because that increases class encapsulation. I consider these two possible implementations for a factory function:
// the less encapsulated design
class Widget {
...
public:
static Widget* make(/* params */);
};
// the more encapsulated design
namespace WidgetStuff {
class Widget { ... };
Widget* make( /* params */ );
};
Andrew Koenig pointed out that the first design (where make is static inside the class) enables one to write a template function that invokes make without knowing the type of what is being made:
template<typename T>
void doSomething( /* params */ )
{
// invoke T's factory function
T *pt = T::make( /* params */ );
...
}
This isn't possible with the namespace-based design, because there's no way from inside a template to identify the namespace in which a type parameter is located. That is, there's no way to figure out what ??? is in the pseudocode below:
template<typename T>
void doSomething( /* params */ )
{
// there's no way to know T's containing namespace!
T *pt = ???::make( /* params */ );
...
}
For factory functions and similar functions which can be given uniform names, this means that maximal class encapsulation and maximal template utility are at odds. In such cases, you have to decide which is more important and cater to that. However, for static member functions with class-specific names, the template issue fails to arise, and encapsulation can again assume precedence. 
Previous Page |
1
|
2
|
 |
|
|||||||||||||||||||||||||||
|
