Bridge Design Pattern in Golang

So we are back again, after a long delay to study the Bridge Design Pattern in Golang. The Bridge Design Pattern is more or less used to avoid unnecessary complexity in code.  Just like the adapter pattern, It is a structural design pattern that allows the separation of abstraction from its implementation. In this article, we will first build an intuition as to why it is used and then code an example to understand the Bridge Design Pattern in Golang.

The pattern suggests dividing a large class/entity into two separate hierarchy.

• Implementation:  It is an interface which binds the core logic of the implementation of a particular task. Its children are called Concrete Implementation and are the main logic behind the functionality we want to achieve. Implementation part remains hidden from the end-user. We don’t want the end-user to know the logic of how a certain thing is working.
• Abstraction: It is also an interface, which just contains the reference to the Implementation. This is the part which is visible to the end-user. Abstraction is an API that makes use of Implementation layer to achieve the functionality.

The Bridge Pattern tries to bridge the gap between Abstraction and Implementation. Bridge Pattern favours Composition over Inheritance.

Let us suppose we have two mobile phones, Samsung and Motorola. Also assume we have two cameras, a front camera and back camera. Both the mobiles need to work with both the cameras. The end-user will work with the Mobile without bothering about the Camera being used.  Instead of creating structs depicting the 4 (2*2) combinations, what we will do is create 2 hierarchies :

• Abstraction Hierarchy
• Implementation Hierarchy

In this diagram, Mobile is the Abstraction and Camera is the implementation.  Both of these hierarchies communicate with each other via Bridge (the arrows). Both of these components are not directly coupled. Mobile does not need to know which Implementation (Camera ) is going to be used for a click. Abstraction holds the reference to the implementation, which can be embedded into it dynamically at the run time.
You do not need to strictly code the relationship into four structs. All the combinations can be achieved at run time using the Bridge Pattern.

Implementation

Let us now try to code this to see how we apply this pattern in Golang.
First of all, let us create the Abstraction and Implementation.

//abstraction

type Mobile interface {
   setCamera(Camera)
   click()
}

//implementation

type Camera interface {
   clickPic()
}

Let us now create instances of these structures.

type Samsung struct {
   Camera Camera
}

func (s *Samsung) setCamera(c Camera) {
   s.Camera = c
}

func (s *Samsung) click() {
   fmt.Println(" Clicking via samsung phone")
   s.Camera.clickPic()
}

ype Motorola struct {
   Camera Camera
}

func (m *Motorola) setCamera(c Camera) {
   m.Camera = c
}

func (m *Motorola) click() {
   fmt.Println("CLicking via motorola phone")
   m.Camera.clickPic()
}

type FrontCamera struct {
}

func (f *FrontCamera) clickPic() {
   fmt.Println("Picture clicked via front camera")
}

type BackCamera struct {
}

func (f *BackCamera) clickPic() {
   fmt.Println("Picture clicked via back camera")
}

And now let us see how to Bridge both these structures.

s := new(Samsung)
m := new(Motorola)
fc := new(FrontCamera)
b := new(BackCamera)

//samsung with front camera
s.setCamera(fc)
s.click()
fmt.Println()

//samsung with back camera
s.setCamera(b)
s.click()
fmt.Println()

//motorola with fron camera
m.setCamera(fc)
m.click()
fmt.Println()

//motorola with back camera
m.setCamera(b)
m.click()

And here is the output of the code.

Clicking via samsung phone
Picture clicked via front camera

Clicking via samsung phone
Picture clicked via back camera

CLicking via motorola phone
Picture clicked via front camera

CLicking via motorola phone
Picture clicked via back camera

Hence, we see how we are able to plug and play the functionalities at run time due to the pattern we followed. This is a very simple use case of Bridge Design Pattern in Golang . We will be coming back with another design pattern in the next blog posts, in the meanwhile, refractor your old projects and decide where you can use this pattern.