Today we will introduce you to the bridge pattern. A software design pattern “is a general, reusable solution to a commonly occurring problem within a given context in software design. […] It is a description or template for how to solve a problem that can be used in many different situations.” (Wikipedia) The bridge pattern is meant to “decouple an abstraction from its implementation so that the two can vary independently” (Wikipedia).
We chose the bridge pattern, because we already implemented it. Each API request-response pattern is defined in an interface and implemented in a separate class. This resembles the degenerate bridge pattern as each abstraction comes with only one implementation. A closer look however reveals that all abstractions extend the interface API. The concrete implementations implement the shared interface Controller. The UML diagram shows a cleanly implemented bridge pattern.
This helps us a lot, because we can define the API definitions separate from the controller, which makes the controller classes much more readable and focused on the underlying functionality.
I hope you can understand that we cannot provide screenshots of the UML diagram before the bridge pattern was implemented without deleting all our code related to it. For your interest, here is the link to the api package in our gitlab: https://gitlab.com/sasep-clairvoyance/sasep-backend/-/tree/develop/src/main/java/io/clairvoyance/api
Link to Bridge pattern in SAD: https://gitlab.com/sasep-clairvoyance/sasep-documents/-/wikis/SAD#52-architecturally-significant-design-packages