What is the design pattern to address the problem of exposing few methods to only certain classes?

As you can see the friend is declared for a certain type. This automatically closes this friend for other types. Like in the link below:

http://www.cprogramming.com/tutorial/friends.html[^]

To guarantee the same for certain methods you can define friend functions that have access to certain data, like:

http://www.exforsys.com/tutorials/c-plus-plus/c-plus-plus-friend-functions.html[^]

The same can be done for operators. Like this:
http://www.devarticles.com/c/a/Cplusplus/C-plus-Tricks-of-the-Trade:-Friend-Functions/2/[^]

Please study the above links very good and maybe try to find extra information about it. Sometimes it's hard to see how this friend construction does the trick. It's therefore considered a no no with a good reason because if you do not understand it completely, the code is unsafe and a big mess. (and c++ errors aren't the most kind ones to understand).

Good luck!

Adapter or Bridge will do the trick. Exactly how you do it depends on what you're trying to adapt or bridge. If you're trying to just expose a few methods and they've got the right interface already then bridge works pretty well. If you want to expose some methods and their signatures are not quite the right shape then use an Adapter.

As Eric said proxy will work as well - although that's usually regarded as a way of exporting an interface over some "hostile" or non-native way of calling it. It's like a bridge but across an external communication mechanism.

Anyway:

- bridge introduces another interface with just the methods in you want to export from the object. You then derive your implementation from the interface and pass a reference to that interface to the consuming object

- adapter introduces a concrete class with the interface you want to consume. You implement that interface using the class to be adapted. You can introduce an interface class to really isolate the adapted class from the consuming class - whether you do that or not is really a matter of taste and how much knowledge of the implementation you're willing to leak across the consumer/adapter boundary

With bridge you'll have to change the class you're bridging to. With adapter you won't. Generally I'd say what you want is an adapter BUT a bridge will help introduce a new concept into your code which will make it easier to factor.

Er, sorry, that's really stream of consciousness isn't it? Please shout if I can (or rather if you'd like me to) clarify anything.

Cheers,

Ash

PS: Most of my experience of this sort of thing has been with C++ so my comments might not be appropriate in general OO terms.

PPS: In response to the comment below, here's what I mean about how to use a bridge. Say I've got a class, A, that uses part of the interface of object of class B:

class B
{
    public:
        void b_a();
        void b_b();
        void b_c();
};

class A
{
    public:
        void a_a( B &b )
        {
            b.b_a();
            b.b_c();
        }
};

so you can see that A doesn't use B::b_b(). Effectively it doesn't need some part of the interface of B.

So to restrict what bits of B A uses we can define a new interface (the bridge solution):

class I
{
    public:
        virtual void b_a() = 0;
        virtual void b_c() = 0;
};

derive B from I:

class B : public I
{
    public:
        void b_a();
        void b_b();
        void b_c();
};

and convert A to use I, not B:

class A
{
    public:
        void a_a( I &i )
        {
            i.b_a();
            i.b_c();
        }
};

So everytime you call the A::a_a you can still pass it a B, but A can't use B::b_b() as it's not part of the interface.

Using an adapter is similar, I can add that if there's any milage.

As mentioned in the comment to Aescleal, I believe what you want to do is narrow the functionality of a class for certain classes. The problem with that is that at runtime (or design time) there is no easy way to to track down who is the caller from which class. And even if you could, it wouldn't become a pretty sight.

I think the most simple way of handling it, is to define certain interfaces with different methods exposed.
Simply create several interfaces like:

public interface Reader { public char read(); }
public interface Writer { public char writer(); }
public interface Opener { public char opener(); }
public interface Closer { public char closer(); }

public class SimpleFile implements Reader, Writer, Opener, Closer {
   ...
}

This way you can simply give each class that uses it an interface of the SimpleFile class with appropriate methods exposed. You could also use extends to combine the interfaces so it is possible to have some overlap.