There's a problem I have with C++, and I'm curious what the D solution is (or if there's a better C++ solution than the one I'm using):

In essence, I want a collection of classes to muck around with each others' internals, but without exposing those same internals to any other classes. (Consider some kind of factory class where the factory directly manipulates the private members of the created object, and then hands that object to some caller.)

My best solution so far is to make the factory a "friend" of the child. However, I really don't like how it lets the factory access *everything* inside the child.

What I'd prefer is to somehow selectively grant access to a subset of methods to another class:

- My ideal solution would be to have the child object implement some
interface, and then permit the factory (but nobody else) to cast to that
interface.
- Second best would be to specify a group of methods that a "friend" class
can access.
- Third best might be to use packages somehow, where classes inside the
package can access each others' protected methods.

As it stands, I'm stuck with using friends, which offer more access than I'd prefer to allow.

Any suggestions?  How do you solve this problem in C++?  How would you solve it in D?

-david

In article <cdn63r$74l$1@digitaldaemon.com>, David Barrett says...
>
>There's a problem I have with C++, and I'm curious what the D solution is (or if there's a better C++ solution than the one I'm using):
>
>In essence, I want a collection of classes to muck around with each others' internals, but without exposing those same internals to any other classes. (Consider some kind of factory class where the factory directly manipulates the private members of the created object, and then hands that object to some caller.)
>
>My best solution so far is to make the factory a "friend" of the child. However, I really don't like how it lets the factory access *everything* inside the child.

One possibility is to put everything in the same package and make that data privcate: "private means that only members of the enclosing class can access the member, or members and functions in the same module as the enclosing class."

You can also get a bit fancy with returning interfaces, but then you might need to come up with a way to make sure that only the classes you want to can actually access that interface.  I've done this kind of thing before in C++ with proxy classes that forward calls via function pointers (which in D would probably involve delegates).  This has the added function of decreasing coupling, which can be occasionally useful.

>- My ideal solution would be to have the child object implement some interface, and then permit the factory (but nobody else) to cast to that interface.

Easiest thing would be to make the method that returns the interface private or protected and then use inheritance or package access to control who can call the method.


Sean

How about reversing your use of Interfaces in this case? I mean, let the factory and its buddies see the full concrete implementation, but expose only a limited Interface to clients via a factory constructor. If you really need to hide the implementation classes completely, you might consider making them private within the same module (or package?) as the factory.

Would that not work? Perhaps I don't understand the question correctly ...


"David Barrett" <dbarrett@quinthar.com> wrote in message news:cdn63r$74l$1@digitaldaemon.com...
> There's a problem I have with C++, and I'm curious what the D solution is (or if there's a better C++ solution than the one I'm using):
>
> In essence, I want a collection of classes to muck around with each
others'
> internals, but without exposing those same internals to any other classes. (Consider some kind of factory class where the factory directly
manipulates
> the private members of the created object, and then hands that object to some caller.)
>
> My best solution so far is to make the factory a "friend" of the child. However, I really don't like how it lets the factory access *everything* inside the child.
>
> What I'd prefer is to somehow selectively grant access to a subset of methods to another class:
>
> - My ideal solution would be to have the child object implement some
> interface, and then permit the factory (but nobody else) to cast to that
> interface.
> - Second best would be to specify a group of methods that a "friend" class
> can access.
> - Third best might be to use packages somehow, where classes inside the
> package can access each others' protected methods.
>
> As it stands, I'm stuck with using friends, which offer more access than
I'd
> prefer to allow.
>
> Any suggestions?  How do you solve this problem in C++?  How would you
solve
> it in D?
>
> -david
>
>

Ah, that's a really good suggestion.  Thanks.

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:cdnctg$93n$1@digitaldaemon.com...
> How about reversing your use of Interfaces in this case? I mean, let the factory and its buddies see the full concrete implementation, but expose only a limited Interface to clients via a factory constructor. If you
really
> need to hide the implementation classes completely, you might consider making them private within the same module (or package?) as the factory.
>
> Would that not work? Perhaps I don't understand the question correctly ...
>
>
> "David Barrett" <dbarrett@quinthar.com> wrote in message news:cdn63r$74l$1@digitaldaemon.com...
> > There's a problem I have with C++, and I'm curious what the D solution
is
> > (or if there's a better C++ solution than the one I'm using):
> >
> > In essence, I want a collection of classes to muck around with each
> others'
> > internals, but without exposing those same internals to any other
classes.
> > (Consider some kind of factory class where the factory directly
> manipulates
> > the private members of the created object, and then hands that object to some caller.)
> >
> > My best solution so far is to make the factory a "friend" of the child. However, I really don't like how it lets the factory access *everything* inside the child.
> >
> > What I'd prefer is to somehow selectively grant access to a subset of methods to another class:
> >
> > - My ideal solution would be to have the child object implement some
> > interface, and then permit the factory (but nobody else) to cast to that
> > interface.
> > - Second best would be to specify a group of methods that a "friend"
class
> > can access.
> > - Third best might be to use packages somehow, where classes inside the
> > package can access each others' protected methods.
> >
> > As it stands, I'm stuck with using friends, which offer more access than
> I'd
> > prefer to allow.
> >
> > Any suggestions?  How do you solve this problem in C++?  How would you
> solve
> > it in D?
> >
> > -david
> >
> >
>
>
>