View mode: basic / threaded / horizontal-split · Log in · Help
July 22, 2004
Interface Access Control
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
July 22, 2004
Re: Interface Access Control
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
July 22, 2004
Re: Interface Access Control
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
>
>
July 22, 2004
Re: Interface Access Control
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
> >
> >
>
>
>
Top | Discussion index | About this forum | D home