[RESOLVED] Somewhat private class?

Desdinova

Hi,

I have a class (called A) that I only want to have accessed by some other classes (for instance class B, C and D).

Is there a structural way to achieve this? I'm working with PHP5.

laserlight

I do not think that is possible in PHP. What do you have in mind in terms of an actual scenario?

Desdinova

hmm

well basically I have a class functioning as an API to other classes. and those other classes should only be collaborating with eachother, and with the API class.

bpat1434

Well, I guess on the abstract you could have class A have all the public methods, then B, C, and D have protected/private methods that aren't accessible from your main php script, but can be from the other (if using protected) or not at all (using private).

Desdinova

But that would mean i have to extend class A right? Else I'd never get in a protected method of class B.

laserlight

Desdinova wrote:
well basically I have a class functioning as an API to other classes. and those other classes should only be collaborating with eachother, and with the API class.

I would like to see a concrete example. At the moment, it still looks like your goal is misguided: there is generally no need to try and enforce such "special membership" in a group of classes.

Desdinova

Well the reason I want this is because I'm not the only programmer, but we're working on the same application.

I'm creating a language pack for instance. we'll call this class LP. LP uses some other classes to achieve its language packing functionality, for instance class XMLpack and SpellCheck.

The classes XMLpack and SpellCheck may only be accessed by LP. If another programmer wishes to use my SpellCheck functions, sure, that's fine, but I want these calls to go through LP. This way LP can specify which calls can and can't be made to my SpellCheck class. It's like a gatekeeper. Behind the gate is the selection of classes I use, and the only way you get to access them is through the gatekeeper.

laserlight

There are two approaches that you may want to consider:

A) Document that the public interface of LP is the actual interface, and that the XMLpack and SpellCheck classes are implementation detail, hence their public interface is subject to change at a whim. You could agree on some kind of naming convention to make such classes more obviously implementation detail.

😎 Separate XMLpack and SpellCheck from LP. LP will still provide the actual "language pack" interface, but "merely" be yet another client of the XMLpack and SpellCheck classes. The obvious disadvantage of this is that you now have another two classes to support, but the advantage is that anyone, even those who do not actually want "language pack" functionality, can use the classes according to the documented interface.

Desdinova

laserlight;10896023 wrote:
There are two approaches that you may want to consider:

A) Document that the public interface of LP is the actual interface, and that the XMLpack and SpellCheck classes are implementation detail, hence their public interface is subject to change at a whim. You could agree on some kind of naming convention to make such classes more obviously implementation detail.

😎 Separate XMLpack and SpellCheck from LP. LP will still provide the actual "language pack" interface, but "merely" be yet another client of the XMLpack and SpellCheck classes. The obvious disadvantage of this is that you now have another two classes to support, but the advantage is that anyone, even those who do not actually want "language pack" functionality, can use the classes according to the documented interface.

OK, so if I understand it right;

A) This is practically the same as simply telling them to only use the LP class and not the others?

😎 all methods in XMLpack and SpellCheck are either protected or private, and both classes extend LP, which contains the public functions?

laserlight

Desdinova wrote:
A) This is practically the same as simply telling them to only use the LP class and not the others?

Yes. You only can use documentation and/or naming convention since there are no language level features that allow you to specify entire classes as implementation detail.

Desdinova wrote:
😎 all methods in XMLpack and SpellCheck are either protected or private, and both classes extend LP, which contains the public functions?

No. In this case you design the classes normally and provide a public interface. The difference is that you have to be more careful about your design of the public interface since the public interface is effectively set in stone since you cater to everyone. If the classes were merely implementation detail instead, you could easily change the public interface to suit your immediate needs.

In terms of overall long term benefit, I would say that option B is better. On the other hand, realistic constraints on time could mean that you may have to choose option A and risk duplication should someone else need such classes but not via the LP class interface.

Desdinova

laserlight;10896033 wrote:
No. In this case you design the classes normally and provide a public interface. The difference is that you have to be more careful about your design of the public interface since the public interface is effectively set in stone since you cater to everyone. If the classes were merely implementation detail instead, you could easily change the public interface to suit your immediate needs.

In terms of overall long term benefit, I would say that option B is better. On the other hand, realistic constraints on time could mean that you may have to choose option A and risk duplication should someone else need such classes but not via the LP class interface.

I tried to google on the 'implementation details' term, but can't really find what it means, or well, how to place it in this context. Could you explain the bold sentence?

laserlight

Desdinova wrote:
I tried to google on the 'implementation details' term, but can't really find what it means, or well, how to place it in this context. Could you explain the bold sentence?

Do you understand the rationale behind having public, protected and private access? The basic idea is that a class would provide an interface open to everyone as given by its public members. It would also provide an interface restricted to its subclasses as given by its protected members. The private members, on the other hand, exist as implementation detail. They are there so that the class can be properly implemented. If at any point a different way of implementing the class is decided on, these private members can be removed, changed, etc, at will.

Now, from your description, you are trying to treat entire classes as implementation detail. That is, the XMLpack and SpellCheck classes exist solely to help implement LP class. Therefore, if any point a different way of implementing the LP class is decided on, any and all members of the XMLpack and SpellCheck classes can be changed. In fact, you could even rename or remove these classes, and all the clients of your LP class should be ignorant of the changes.

Desdinova

laserlight;10896042 wrote:
Do you understand the rationale behind having public, protected and private access? The basic idea is that a class would provide an interface open to everyone as given by its public members. It would also provide an interface restricted to its subclasses as given by its protected members. The private members, on the other hand, exist as implementation detail. They are there so that the class can be properly implemented. If at any point a different way of implementing the class is decided on, these private members can be removed, changed, etc, at will.

Now, from your description, you are trying to treat entire classes as implementation detail. That is, the XMLpack and SpellCheck classes exist solely to help implement LP class. Therefore, if any point a different way of implementing the LP class is decided on, any and all members of the XMLpack and SpellCheck classes can be changed. In fact, you could even rename or remove these classes, and all the clients of your LP class should be ignorant of the changes.

Yes the public, protected and private encapsulation is clear to me. I never heard of implementation detail before, but if I understand it right, everything that can only be accessed 'internally' is called implementation detail?

The bold sentence cleared things up for me.

But looking at how it should be coded, that would mean I still need to use public functions in the XMLpack and SpellCheck classes right? Else I wouldn't be able to access them from LP.. And the LP will have public functions too, which would function as the actual interface. Right?

laserlight

Desdinova wrote:
But looking at how it should be coded, that would mean I still need to use public functions in the XMLpack and SpellCheck classes right? Else I wouldn't be able to access them from LP.. And the LP will have public functions too, which would function as the actual interface. Right?

Yes.

Desdinova

laserlight;10896048 wrote:
Yes.

Haha ok.

That would pretty much mean I still need to tell other programmers to only use LP. Which actually makes the two options I had, just one really.

As a matter of fact, that would change nothing in the way it's coded right now. So basically the answer to the question is: can't be done in PHP.

Thanks for your help. I appreciate it.