Design Question: Inheritance or Accessors

[Ben Pope]

Hi everybody,

I know this is not usually the place for design questions, but I was wondering what some of you more experienced people would do.

Say I have an application that has a C++ & STL core, with a user interface that could be command-line (on topic, I guess) or even .NET/QT/Whatever UI (obviously off-topic, here).

One of the classes in the core stores some data, in a vector. I want to display that information to the user.

Is it preferable to provide an accessor for the private data, e.g.:

std::vector<T> GetData() const {
return storage_;
}

With which the UI can obtain the data - which obviously loses some of my encapsulation, or would it be preferable to make the storage protected, and have the UI component inherit
from the class (probably multiple inheritance required in this case)?

I would prefer not to have any dependency of the UI within the core, so making the UI a friend would be difficult.

Cheers!

Ben
--
I'm not just a number. To many, I'm known as a String...

[Dan Cernat]

"Ben Pope" <benpope81@_REMOVE_gmail.com> wrote in message
news:1122234898.3f87a0a1ac3b33b90f608e8290e7df8e@t eranews...

Hi everybody,

I know this is not usually the place for design questions, but I was
wondering what some of you more experienced people would do.

Say I have an application that has a C++ & STL core, with a user interface
that could be command-line (on topic, I guess) or even .NET/QT/Whatever UI
(obviously off-topic, here).

One of the classes in the core stores some data, in a vector. I want to
display that information to the user.

Is it preferable to provide an accessor for the private data, e.g.:

std::vector<T> GetData() const {
return storage_;
}

I would return const reference to data. This way one cannot change it.

const std::vector<T>& GetData() const
{
return storage_;
}

Dan

[Cy Edmunds]

"Ben Pope" <benpope81@_REMOVE_gmail.com> wrote in message
news:1122234898.3f87a0a1ac3b33b90f608e8290e7df8e@t eranews...

Hi everybody,

I know this is not usually the place for design questions, but I was
wondering what some of you more experienced people would do.

Say I have an application that has a C++ & STL core, with a user interface
that could be command-line (on topic, I guess) or even .NET/QT/Whatever UI
(obviously off-topic, here).

One of the classes in the core stores some data, in a vector. I want to
display that information to the user.

Is it preferable to provide an accessor for the private data, e.g.:

std::vector<T> GetData() const {
return storage_;
}

With which the UI can obtain the data - which obviously loses some of my
encapsulation, or would it be preferable to make the storage protected,
and have the UI component inherit from the class (probably multiple
inheritance required in this case)?

I would prefer not to have any dependency of the UI within the core, so
making the UI a friend would be difficult.

Cheers!

Ben
--
I'm not just a number. To many, I'm known as a String...

I would give the user some iterators:

template <typename T>
class YourClass {
public:
typedef std::vector<T> t_container;
typedef t_container::const_iterator const_iterator;
const_iterator begin() const {return storage_.begin();}
const_iterator end() const {return storage_.end();}
....
};

A smart client should be able to write his code in such a way that nothing
breaks if you change to a different container type.

--
Cy
http://home.rochester.rr.com/cyhome/

[Ben Pope]

Dan Cernat wrote:

"Ben Pope" <benpope81@_REMOVE_gmail.com> wrote in message
news:1122234898.3f87a0a1ac3b33b90f608e8290e7df8e@t eranews...

Is it preferable to provide an accessor for the private data, e.g.:

std::vector<T> GetData() const {
return storage_;
}

I would return const reference to data. This way one cannot change it.

const std::vector<T>& GetData() const
{
return storage_;
}

You'd prefer const reference over copy by value?

My original question was going to be over this particular issue, but I thought by-value was generally preferred, and then I thought of the inheritance thing, and wondered about
that "more".

Cheers,

Ben
--
I'm not just a number. To many, I'm known as a String...

[Ben Pope]

Cy Edmunds wrote:

"Ben Pope" <benpope81@_REMOVE_gmail.com> wrote in message
news:1122234898.3f87a0a1ac3b33b90f608e8290e7df8e@t eranews...

Is it preferable to provide an accessor for the private data, e.g.:

std::vector<T> GetData() const {
return storage_;
}

I would give the user some iterators:

template <typename T>
class YourClass {
public:
typedef std::vector<T> t_container;
typedef t_container::const_iterator const_iterator;
const_iterator begin() const {return storage_.begin();}
const_iterator end() const {return storage_.end();}
...
};

A smart client should be able to write his code in such a way that nothing
breaks if you change to a different container type.

Hmm, interesting. I had toyed briefly with that idea, but hadn't formulated any real ideas.

I suppose the whole point is not to return the vector, giving access to the iterators, but to return the iterators themselves.

Is it possible to return a "forward container"? I don't see that as some concrete interface or base class anywhere in the STL, I presume it's "just" a concept, not tangible?

I suppose I could enforce a similar effect by doing:

typedef t_container::forward_iterator forward_iterator;

And if I wanted to be able to do:
*(YourClass.begin() + 4);

typedef t_container::random_access_iterator random_access_iterator;

This is very interesting.

I must re-read some of the STL concepts with a different hat on (one that asks how I would give my class these concepts, rather then how I can use these concepts).

Thank you.

Ben
--
I'm not just a number. To many, I'm known as a String...

[Ben Pope]

Ben Pope wrote:

Cy Edmunds wrote:

I would give the user some iterators:

template <typename T>
class YourClass {
public:
typedef std::vector<T> t_container;
typedef t_container::const_iterator const_iterator;
const_iterator begin() const {return storage_.begin();}
const_iterator end() const {return storage_.end();}
...
};

A smart client should be able to write his code in such a way that
nothing breaks if you change to a different container type.

Hmm, interesting. I had toyed briefly with that idea, but hadn't
formulated any real ideas.

I suppose the whole point is not to return the vector, giving access to
the iterators, but to return the iterators themselves.

Just for a laugh, say I wanted to implement that storage stuff as part of a policy, should I be doing something like the following?

#include <vector>

typedef unsigned short uint16;
typedef unsigned char uint8;

/**
* Storage Policy based on a std::vector.
*/
template<class T>
class VectorStorage {
public:
typedef std::vector<T> t_container;
typedef typename t_container::size_type size_type;
typedef typename t_container::const_iterator const_iterator;

const_iterator begin() const {return storage_.begin();}
const_iterator end() const {return storage_.end();}
private:
t_container storage_;
};

/**
* Storage Policy based on an array.
*/
template<typename T>
class ArrayStorage {
public:
typedef T* t_container;
typedef uint16 size_type;
typedef const T* const_iterator;

ArrayStorage(size_type size = 8) : size_(size), storage_(new T[size]) {}
~ArrayStorage() {delete[] storage_;}

const_iterator begin() const {return storage_;}
const_iterator end() const {return storage_ + size_;}
private:
size_type size_;
t_container storage_;
};

....not that I'd want to use an array, usually, but if for some strange reason...

That would seem to abstract my implementation of storage_ from the user of the class, wouldn't it?

I could then publicly inherit either of those classes, and specify which one with a template parameter.

Cheers!

Ben
--
I'm not just a number. To many, I'm known as a String...

[Cy Edmunds]

"Ben Pope" <benpope81@_REMOVE_gmail.com> wrote in message
news:1122250402.ba1ed96ef1ac23d9b40f5f5f364f5a1b@t eranews...

Ben Pope wrote:

Cy Edmunds wrote:

I would give the user some iterators:

template <typename T>
class YourClass {
public:
typedef std::vector<T> t_container;
typedef t_container::const_iterator const_iterator;
const_iterator begin() const {return storage_.begin();}
const_iterator end() const {return storage_.end();}
...
};

A smart client should be able to write his code in such a way that
nothing breaks if you change to a different container type.

Hmm, interesting. I had toyed briefly with that idea, but hadn't
formulated any real ideas.

I suppose the whole point is not to return the vector, giving access to
the iterators, but to return the iterators themselves.

The point is to make your classes maintainable by not putting implementation
details (such as which container you decided to use) right at the interface.
For instance if you started with std::vector but later decided to switch to
ArrayStorage no client code should break.

Just for a laugh, say I wanted to implement that storage stuff as part of
a policy, should I be doing something like the following?

#include <vector>

typedef unsigned short uint16;
typedef unsigned char uint8;

/**
* Storage Policy based on a std::vector.
*/
template<class T>
class VectorStorage {
public:
typedef std::vector<T> t_container;
typedef typename t_container::size_type size_type;
typedef typename t_container::const_iterator const_iterator;

const_iterator begin() const {return storage_.begin();}
const_iterator end() const {return storage_.end();}
private:
t_container storage_;
};

/**
* Storage Policy based on an array.
*/
template<typename T>
class ArrayStorage {
public:
typedef T* t_container;
typedef uint16 size_type;
Hm, just wondering why you would limit your array size to 32K elements. I
would probably use size_t here.
typedef const T* const_iterator;

ArrayStorage(size_type size = 8) : size_(size), storage_(new T[size])
{}
You should declare this one explicit -- you don't really want automatic
conversion from uint16 to ArrayStorage<T>.
~ArrayStorage() {delete[] storage_;}
Now you must include
ArrayStorage(const ArrayStorage<T> &);
and
ArrayStorage &operator = (const ArrayStorage<T> &);

Otherwise innocent looking code like
ArrayStorage<int> a1(3);
ArrayStorage<int> a2(a1);

will cause undefined behavior when storage_ gets deleted twice. Boost has a
reference counted smart pointer for arrays which might do what you want as
far as copy semantics are concerned.

const_iterator begin() const {return storage_;}
const_iterator end() const {return storage_ + size_;}
private:
size_type size_;
t_container storage_;
};

...not that I'd want to use an array, usually, but if for some strange
reason...

That would seem to abstract my implementation of storage_ from the user of
the class, wouldn't it?

I could then publicly inherit either of those classes, and specify which
one with a template parameter.
Better yet, you could encapsulate this object in your new object. This one
wasn't really made as a base class. For instance, no virtual destructor. I
think encapsulation should generally be preferred over inheritance with a
concrete data type like this.

Cheers!

Ben
--
I'm not just a number. To many, I'm known as a String...

--
Cy
http://home.rochester.rr.com/cyhome/

[Dan Cernat]

Ben Pope wrote:

Dan Cernat wrote:

"Ben Pope" <benpope81@_REMOVE_gmail.com> wrote in message
news:1122234898.3f87a0a1ac3b33b90f608e8290e7df8e@t eranews...

Is it preferable to provide an accessor for the private data, e.g.:

std::vector<T> GetData() const {
return storage_;
}

I would return const reference to data. This way one cannot change it.

const std::vector<T>& GetData() const
{
return storage_;
}

You'd prefer const reference over copy by value?

My original question was going to be over this particular issue, but I thought by-value was generally preferred, and then I thought of the inheritance thing, and wondered about
that "more".

Cheers,

Ben
--
I'm not just a number. To many, I'm known as a String...

think of std::string::c_str() method. It returns a pointer to the
internal data.

Dan

[Martin Eisenberg]

Ben Pope wrote:

Is it possible to return a "forward container"? I don't see
that as some concrete interface or base class anywhere in the
STL, I presume it's "just" a concept, not tangible?

I suppose I could enforce a similar effect by doing:

typedef t_container::forward_iterator forward_iterator;

And if I wanted to be able to do:
*(YourClass.begin() + 4);

typedef t_container::random_access_iterator
random_access_iterator;

The standard containers don't have such members. Rather, a given
container type's iterators belong to a specific category (and its
restrictions). Read http://www.sgi.com/tech/stl/iterator_tags.html.
If you want your class always to provide iterators of a given
category, you will have to adapt in the storage policy for a
container type with less capable iterators.
Martin

--
Quidquid latine dictum sit, altum viditur.