A traversal problem

[Kaba]

Hello

I have a design problem, which I don't seem to have a good solution. By
example:

class B;
class C;

class D
{
public:
// Something
};

class A
{
public:
void clear();
int numberOfBs() const;
private:
map<integer, B*> data_;
};

class B
{
public:
void clear();
int numberOfCs() const;
private:
map<integer, C*> data_;
};

class C
{
public:
void clear();
int numberOfDs() const;
private:
vector<D> data_;
};

The similar interfaces is just a coincidence. As you can see the classes
form a hierarchy. This hierarchy is only finite, that is, I am not after
something like composite pattern.

The class hierarchy is made to partition the D data into chunks which
are more conveniently used in the program.

Now, the data in the Ds is the one that should be modifiable by a user.
The user should not be able to use the non-const functions in B and C
(such as clear). The user should only be able to modify the data in Ds
and use the const functions.

It is like the interfaces should be partitioned into two: one for the
"administra tor" and one for the "user". On the other hand, I think
iterators must be used in any case, but how do you satisfy the non-const
requirements?

I hope this description is not too vague.

So how do you traverse all D's in all C's in all B's in all A's with
these requirements?

--
Kalle Rutanen
http://kaba.hilvi.org

[Alf P. Steinbach]

* Kaba:

So how do you traverse all D's in all C's in all B's in all A's with
these requirements?

The requirements seem to be that C, B and A should be non-modifyable
from the client code.

Then expose interfaces, not C, B and A themselves.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Victor Bazarov]

Kaba wrote:

I have a design problem, which I don't seem to have a good solution.
By example:

class B;
class C;

class D
{
public:
// Something
};

class A
{
public:
void clear();
int numberOfBs() const;
private:
map<integer, B*> data_;
};

class B
{
public:
void clear();
int numberOfCs() const;
private:
map<integer, C*> data_;
};

class C
{
public:
void clear();
int numberOfDs() const;
private:
vector<D> data_;
};

The similar interfaces is just a coincidence. As you can see the
classes form a hierarchy. This hierarchy is only finite, that is, I
am not after something like composite pattern.

The class hierarchy is made to partition the D data into chunks which
are more conveniently used in the program.

Now, the data in the Ds is the one that should be modifiable by a
user. The user should not be able to use the non-const functions in B
and C (such as clear). The user should only be able to modify the
data in Ds and use the const functions.
So, why aren't those functions that the user isn't supposed to use
declared 'private' then?
It is like the interfaces should be partitioned into two: one for the
"administra tor" and one for the "user".
There are several solutions for this. You can declare the 'adminstrator'
a friend of those classes. You can provide a derived class for all the
administrative needs and keep the administration interface 'protected'...
On the other hand, I think
iterators must be used in any case, but how do you satisfy the
non-const requirements?
Make your iterators 'const' up until when they dereference to 'D&'.
I hope this description is not too vague.
Uh.. Maybe just a bit.
So how do you traverse all D's in all C's in all B's in all A's with
these requirements?

I would probably write a bunch of 'for_each' member functions.

You didn't specify what your user gets to work with. What does he/she
have? An instance of 'A'?

V
--
Please remove capital As from my address when replying by mail

[Kaba]

This is to both Alf and Victor. Thanks for the replies.

Alf: A is modifyable, while B and C accessed through A are not. The user
is given A. I didn't quite get your answer of exposing interfaces.. Did
you mean to encapsulate B and C totally inside A?

Now, the data in the Ds is the one that should be modifiable by a
user. The user should not be able to use the non-const functions in B
and C (such as clear). The user should only be able to modify the
data in Ds and use the const functions.
So, why aren't those functions that the user isn't supposed to use
declared 'private' then?

It is because the classes themselves, each A, B, C and D should also be
useable by themselves.

It is like the interfaces should be partitioned into two: one for the
"administra tor" and one for the "user".

There are several solutions for this. You can declare the 'adminstrator'
a friend of those classes. You can provide a derived class for all the
administrative needs and keep the administration interface 'protected'...

Yes, I also thought of this.. But then I would have to lose the property
that the classes were usable by themselves..

On the other hand, I think
iterators must be used in any case, but how do you satisfy the
non-const requirements?

Make your iterators 'const' up until when they dereference to 'D&'.

This protects the pointers from modification, but when you get the
pointer to B, for example, you are again free to modify it as you wish.
On the other hand, if in some way during the chain from A to D the
object is const, then D is also and can't be modified.

I hope this description is not too vague.
Uh.. Maybe just a bit.

Probably a lot, I am sorry:)
I would probably write a bunch of 'for_each' member functions.

You didn't specify what your user gets to work with. What does he/she
have? An instance of 'A'?

Yes, the user gets the A.

Now, I know the problem description is not enough. So I try again with
my actual application.

I am programming a music composing programming. The top class A is
called Tune. This contains the instruments and notes etc.

The note information in Tune (A) is a collection of Patterns.
A Pattern (B) is a collection of Channels.
A Channel (C) is a collection notes (D).

A Channel is similar to a staff. A Pattern is a collection of parallel
staffs (for example, piano and bass can play at the same time) of some
finite time, kind of blocks. The Tune is then a collection of these
blocks.

The time in a Channel is discretely divided into pieces. The user (well,
a programmer using the api), should be able to directly write and read
these time pieces (write note there, clear that note, etc..).

But the user should also have access to the larger pieces, such as
Patterns, so he can read something useful from it. As the Patterns and
Channels are organized by Tune, the user should not have modification
access to them.

--
Kalle Rutanen
http://kaba.hilvi.org