Re: Proper use of templated containers as class members
On Dec 4, 5:15 am, Per <p...@isy.liu.se> wrote:
I am finding myself doing the following rather often when I have
template containers in classed, e.g. stl::map
For example:
class Foo
{
public:
typedef std::map<std::string, int> direcory_t;
//More typedefs of the same style...
private:
directory_t directory_m;
//More members of the same style...
public:
//Constructors and stuff
const directory_t& directory() const {return directory_m;}
};
The question is what is your opinion on typedefing like this. At the
same time as it saves a lot of typing. After a while there are very
many types in a project. And in the end can get confusing about what
the type really contains. Classes should of course hide their
implementation but it seams very stupid not to have read access
directly to a member. If I didn't have that I have to bloat the class
with wrapper functions for the members. And not using typedefs would
lead to an awful lot of typing.
Victor's advice is excellent, as usual.
Maxim and Jeff discussing this produced a thought.
Do you in fact need to expose this through the
interface of the class? Essentially what you have
there is a "getter" function.
const directory_t& directory() const {return directory_m;}
This exposes that the class contains something of
type directory_t, and so needs to expose the type also.
In principle, it exposes that there is a data member
of that type. (Though, in general, it only implies that
the class can proffer up data in that form. Recall the
evergreen discussions about a point class that can
provide x-y data or r-theta data.)
Usually what this means is that you have a fairly
thin abstraction in the class. That is, you've let
some of the functionality to do with the directory_t
type members get outside the class.
Think of the class Foo as an exporter of some service.
Is that service just "work as a holder of a member of
type directory_t"? Sometimes that is appropriate.
It is certainly not a good idea to prohibit such things
as sometimes such a simple "bag of data" is very useful.
But maybe what should happen is that you refactor a
bit and so keep all knowledge of the directory_t
type object inside the class Foo. Maybe the code
that needs to know that such a type, and a member
of that type, exists, maybe all that code should be
inside the class Foo. (Or possibly a very tightly
related small collection of classes. And then you
probably want to look up the proper uses of friend.)
That way, the class Foo could become an exporter of
a higher level service such as (from the name
"directory") "look after all the tasks required
to deal with a telephone directory". (Or whatever
it's a directory of.) Then the typedef is not used
outside the class.
Socks