Is that still the bridge pattern where the implementation derives from the abstraction?

Question

When delivering public API classes that are not meant for derivation I find it more convenient to deliver the implementation of them by deriving from them rather than adding and implementing bridges.

The implementation of an abstraction does not have to be replaceable. The only requirement is to separate the implementation from the abstraction (the public interface).

PublicApiAssembly.dll:

public abstract class PublicApi // Clients don't need to derive from it
{
    internal PublicApi() {}
    public abstract void Calculate();
}

ImplementationAssembly.dll (references PublicApiAssembly.dll and all other dependencies to implement the abstraction):

internal class PublicApiImpl : PublicApi
{
    public override void Calculate() {}
}

Is that still the bridge pattern where the implementation derives from the abstraction, please?

Wikipedia made me think that this is an implementation of the bridge pattern when saying "can use inheritance to separate responsibilities".

Thanks!

Answer 1

The main point of the bridge pattern is to "decouple an abstraction from its implementation so that the two can vary independently". The abstraction can vary through inheritance, while the implementation can vary by different implementations. This is no longer true with your design. You intentionally decided that the abstraction won't vary ("public API classes that are not meant for derivation") and tied the implementation to the abstraction via inheritance. So IMHO there isn't left enough of the bridge pattern here to justify referring to it.

As a side note:

The only requirement is to separate the implementation from the abstraction (the public interface).

Any reason why you model PublicApi as an abstract class instead of an interface? From what I read from your question an interface would be the better match to your intentions.