• David Barrett (24/24) Jul 21 2004 There's a problem I have with C++, and I'm curious what the D solution i...
• Sean Kelly (14/27) Jul 21 2004 One possibility is to put everything in the same package and make that d...
• Kris (12/36) Jul 21 2004 How about reversing your use of Interfaces in this case? I mean, let the
• David Barrett (7/52) Jul 21 2004 Ah, that's a really good suggestion. Thanks.

"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

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

"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

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

"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

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