2

There are a lot of questions on SO comparing Bridge pattern and Strategy pattern. Explanations include

Bridge is structural and Strategy is behavioral

and

UML and code look similar but the intent is different

among other less common ones.

None of those explanations I've come across here or elsewhere is satisfactory. I clearly know when I am using the Strategy pattern and Bridge pattern because of my intention and the problem I need to solve but from a distance, the distinction gets blurred. Thus, this question keeps my mind busy time to time.

If I use the Bridge pattern when modeling the structure of the components, doesn't it become Strategy pattern at runtime, naturally?

Edit: On requesti I am adding SO questions

This answer says that UML diagram and code are similar but the reason for usages may differ. This answer says that their syntaxes are similar but goals are different. This answer says that one of them is structural and the other is behavioral. This answer got very close but at the end, there is no single reason why bridge is also strategy at runtime. This answer is also a worth reading but it still begs the same question; does Bridge pattern becomes Strategy pattern at runtime? Is our intention the only difference?

Edit 2: I would like to ask it differently. Looking only a source code, let's say this Strategy Pattern example and this Bridge Pattern example, how can you tell Bridge pattern from Strategy pattern? It seems like we can swap these to sample codes and tutorials still make sense.

ozgur
  • 2,549
  • 4
  • 25
  • 40
  • 1
    Please link the SO questions you are quoting from. – jaco0646 Sep 27 '18 at 19:26
  • The best comparison of the two patterns is here: https://stackoverflow.com/a/29545680/1371329 – jaco0646 Sep 27 '18 at 19:49
  • @jaco0646 I will edit. By the way, I am not quoting I am summarizing. – ozgur Sep 27 '18 at 20:19
  • @jaco0646 the link you provided has a good answer. But my question is slightly different. – ozgur Sep 27 '18 at 20:37
  • @ozgur The problem is that your linked Bridge example is oversimplified. For example, it doesn't use any of the properties of the Circle class, unlike the [Wikipedia version](https://en.wikipedia.org/wiki/Bridge_pattern). If you don't use properties, then you are only considering behaviour and not structure and is one reason your example almost reduces to Strategy. – pere57 Oct 03 '18 at 12:11
  • @pere57 Then Bridge pattern is a superset of Strategy pattern? If I use only methods, not properties, then it becomes Strategy pattern. – ozgur Oct 03 '18 at 19:03

1 Answers1

3

The superficial comparisons between Bridge and Strategy seem to focus on the composition relationship between each pattern's main components. This relationship is a spurious basis for comparison, because a majority of GoF design patterns employ composition (hence their famous principle, "Favor object composition over class inheritance.")

In contrast, note the composition relationship in a Bridge links one abstraction to another, whereas the composition relationship in a Strategy links an implementation to an abstraction. A Bridge is useful when the client depends on an (abstract) API that is implemented in terms of a separate, differing API. Strategy is useful when the client is a concrete implementation whose behavior can be modified by using multiple algorithms.

There is also a difference in the scope of abstraction between these patterns. Bridge uses one API to implement another entirely. The client API delegates all calls to the implementor (invisibly to the client). Strategy uses an API as one piece of a client implementation. A strategy does not implement the entire client API.

Summary

Bridge

  • Abstraction has-a Abstraction
    1. The first abstraction is the client API.
    2. The second abstraction is the implementor API.
  • The implementor is hidden from the client and does not match the client API.
  • The client API forwards all calls to the implementor.

Strategy

  • Implementation has-a Abstraction
    1. The implementation is the client, or an object constructed by the client.
    2. The abstraction is the Strategy API.
  • A concrete strategy is chosen by the client, so its API is known and matches the client's requirement.
  • The client implementation forwards one specific operation to the strategy. The remainder of the client API is unrelated to that strategy.

Finally, note that neither of these patterns are particularly common in modern OOP. Bridge is a niche case that requires a priori planning, while Strategy is now supported natively via lambdas or closures.

jaco0646
  • 15,303
  • 7
  • 59
  • 83
  • Bridge is closely related to Adapter. The [Difference between Bridge pattern and Adapter pattern](https://stackoverflow.com/a/60067236/1371329) may clear up some confusion here as well. – jaco0646 Feb 05 '20 at 00:12