2

In one of my projects, I'm using the following pattern at several places: I have a class A with a bunch of methods, and class B which gets constructed with a pointer to some instance of A, exporting only a subset of those methods for a user (which is not the owner of the A instance).

class A
{
public:
    void doStuff();
    void doOtherStuff();
    void doYetOtherStuff();
    B getB()
    {
        return B(this);
    }
};

class B
{
    friend class A;

public:
    void doStuff()
    {
        _a->doStuff();
    }

    void doOtherStuff()
    {
        _a->doOtherStuff();
    }

private:
    B(A* a) : _a(a) {}
    A* _a;
};

An instance of A could be created by my library, for example, and a created instance of B (associated with an A) could be passed to a plugin, which will still have access to the A instance, albeit in a limited way.

I'm just confused regarding the design pattern name of B: is it a façade, a bridge, an adapter or a proxy? Or something else?

Dave Schweisguth
  • 36,475
  • 10
  • 98
  • 121
eepp
  • 7,255
  • 1
  • 38
  • 56

2 Answers2

1

In this case, I would advise checking Huston Design Patterns. At the end of each pattern it cites the GoF and gives the differences between the current pattern and related patterns.

For example, on Proxy we can read:

Adapter provides a different interface to its subject. Proxy provides the same interface. Decorator provides an enhanced interface. [GoF. p216]

Therefore, since you are restricting the interface this is closer to an Adapter, though we still need to check Bridge and Facade.

If we check Adapter, we get other nuggets:

Bridge is designed up-front to let the abstraction and the implementation vary independently. Adapter is retrofitted to make unrelated classes work together. [GoF, p161]

Facade defines a new interface, whereas Adapter reuses an old interface. Remember that Adapter makes two existing interfaces work together as opposed to defining an entirely new one. [GoF, pp219]

However they are not as telling. At this point it is less clear because the design is not the sole contributor to the name, the intent also matters. A Facade is about hiding complexity and a Bridge is about de-correlating orthogonal dimensions: neither apply here.

Thus we are left with Adapter.

Community
  • 1
  • 1
Matthieu M.
  • 287,565
  • 48
  • 449
  • 722
0

Without any more context, I would call it a delegate. B is delegating responsibility for doing stuff to A.

This is an extremely common pattern in Cocoa / UIKit programming, particularly if A is a fairly abstract type - this would be more the case if A was just an interface that any class could implement.

However if you are simplifying an interface and especially if B's lifecycle is brief (just existing to simplify access to A) then yes that's a facade pattern.

On the other patterns - none is completely ruled out but here are my thoughts:

An adapter would generally be changing the interface - that is the client of B wants to call doStuff(), but A has some other interface (maybe more complex or domain-specific) that the client doesn't want to have to deal with, so B adapts the A's interface to the interface the client wants.

A proxy would generally involve representation of some remote or less accessible or instantiable object; A's accessibility makes it seem less of a proxy pattern here but a proxy could certainly wrap an API call of the same name.

If the implementation of A can vary and B hides that fact from the client, this could suggest a strategy pattern.

Corbell
  • 1,283
  • 8
  • 15