Re: avoid inheritance from std::map
On Dec 16, 3:54 am, "Hicham Mouline" <hic...@mouline.org> wrote:
"Juha Nieminen" <nos...@thanks.invalid> wrote in message
news:ZcA1l.485$M21.77@read4.inet.fi...
Hicham Mouline wrote:
we have bits of code where we inherit from std::map.
Why again shouldn't one inherit from STL containers in the C++ runtime=
s?
The proposal is to write a
template <typename Key, typename Value>
class MapDecorator {
//replicate map's interface here and simply forward all calls to m=
_
private:
std::map<Key,Value> m_;
}
and then inherit from MapDecorator <....>
I agree one shouldn't inherit from std::map, though I don't remember w=
hy,
However the above seems to me redundant?
It may be a question of abstraction.
By inheriting directly from std::map you may be (rather ironically)
breaking good object-oriented design principles related to modularity
and abstraction. That's because you are fully exposing the data
container you are using in your class (as your class *is* the data
container).
Sometimes that doesn't matter. If your class really *is* a map, just
with added functionality, then it usually is ok.
However, if your class is trying to represent some higher concept,
then by exposing to the outside that it really is a std::map, you are
lessening its abstraction. In some cases this can make it very difficul=
t
to, for example, change the data container implementation in the future=
..
Usually you don't really want to replicate the entire std::map
interface in your class. You want to implement what you class can do.
Whether it internally uses an std::map or something else (such as a
hash_map or whatever) should be a hidden implementation detail.
If we just replicate part of map's public interface in MapDecorator<> abo=
ve,
and inherit from MapDecorator<>, then aren't we in the same situation?
MapDecorator also hasn't been designed to be a base class.
Should we change tjhe map's interface that we replicate to be virtual
functions insead,
and to add a virtual destructor,
then we'd get rid of 1 reason why we shouldn't inherit from STL container=
s.
Our classes are curves of datapoints (x,y)- Hide quoted text -
- Show quoted text -
The correct way to do this IMHO (and picking up on Juha's
suggestions)...
Make MapDecorator *contain* a map as part of it's (private) data and
expose what you need of it's functionality via accessor functions.
This gets you encapsulation.
If MapDecorator is going to function as a base class for derived
classes, then, and only then, make it have a virtual destructor. Make
other functions virtual (or not) only if needed. There are clear
guidelines as to whether you make a non-destructor function non-
virtual, virtual, or pure-virtual. I'm sure they're in the FAQ but I
learned the guidelines from Meyers.
Also, I would rename MapDecorator to something more domain specific so
it's clearer.
HTH