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
"administrator" 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