www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Interface Access Control

reply "David Barrett" <dbarrett quinthar.com> writes:
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
Jul 21 2004
next sibling parent Sean Kelly <sean f4.ca> writes:
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
Jul 21 2004
prev sibling parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
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

 internals, but without exposing those same internals to any other classes.
 (Consider some kind of factory class where the factory directly

 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

 prefer to allow.

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

 it in D?

 -david

Jul 21 2004
parent "David Barrett" <dbarrett quinthar.com> writes:
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

 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


 (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

 internals, but without exposing those same internals to any other


 (Consider some kind of factory class where the factory directly

 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"


 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

 prefer to allow.

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

 it in D?

 -david


Jul 21 2004