For the class diagram and the code example, let's imagine that we are writing a library that hashes passwords. In practice, storing passwords in plain text is something that should be avoided. This is what our library will help our users to do. There are many different hashing algorithms that can be used. Some are SHA-1, MD5, and SHA-256. We want to be able to support at least these and have the possibility to add new ones easily. There are different hashing strategies—you can hash multiple times, combine different hashes, add salt to the passwords, and so on. These strategies make our passwords harder to guess using rainbow tables, for example. For this example, we will show hashing with salt and simple hashing with any of the algorithms we have.

Here is our class diagram:

As you can see from the preceding diagram, we separated the implementation (Hasher and it's implementations) from the abstraction (PasswordConverter). This allows us to easily add a new hashing implementation and then instantly use it by just providing an instance of it when creating a PasswordConverter. If we hadn't used the preceding builder pattern, we would probably have to create a password converter for each hashing algorithm separately—something that would make our code explode in size or become tedious to use.

Let's now have a look at the previous class diagram from the point of view of Scala code. First, we will focus on the implementation side with the Hasher trait:

trait Hasher {
  def hash(data: String): String
  
  protected def getDigest(algorithm: String, data: String) = {
    val crypt = MessageDigest.getInstance(algorithm)
    crypt.reset()
    crypt.update(data.getBytes("UTF-8"))
    crypt
  }
}

Then, we have three classes that implement it—Md5Hasher, Sha1Hasher, and Sha256Hasher. Their code is pretty simple and similar, but yields different results:

class Sha1Hasher extends Hasher {
  override def hash(data: String): String = new String(Hex.encodeHex(getDigest("SHA-1", data).digest()))
}

class Sha256Hasher extends Hasher {
  override def hash(data: String): String = new String(Hex.encodeHex(getDigest("SHA-256", data).digest()))
}

class Md5Hasher extends Hasher {
  override def hash(data: String): String = new String(Hex.encodeHex(getDigest("MD5", data).digest()))
}

Let's now take a look at the abstraction side of things. This is what our clients will use. The following listing shows the PasswordConverter:

abstract class PasswordConverter(hasher: Hasher) {
  def convert(password: String): String
}

We have chosen to provide two different implementations here—SimplePasswordConverter and SaltedPasswordConverter. The code for them is as follows:

class SimplePasswordConverter(hasher: Hasher) extends PasswordConverter(hasher) {
  override def convert(password: String): String = hasher.hash(password)
}

class SaltedPasswordConverter(salt: String, hasher: Hasher) extends PasswordConverter(hasher) {
  override def convert(password: String): String = hasher.hash(s"${salt}:${password}")
}

Now, if a client wanted to use our library, they could write a program similar to the following one:

object BridgeExample {
  
  def main(args: Array[String]): Unit = {
    val p1 = new SimplePasswordConverter(new Sha256Hasher)
    val p2 = new SimplePasswordConverter(new Md5Hasher)
    val p3 = new SaltedPasswordConverter("8jsdf32T^$%", new Sha1Hasher)
    val p4 = new SaltedPasswordConverter("8jsdf32T^$%", new Sha256Hasher)
    
    System.out.println(s"'password' in SHA-256 is: ${p1.convert("password")}")
    System.out.println(s"'1234567890' in MD5 is: ${p2.convert("1234567890")}")
    System.out.println(s"'password' in salted SHA-1 is: ${p3.convert("password")}")
    System.out.println(s"'password' in salted SHA-256 is: ${p4.convert("password")}")
  }
  
}

The output of this example application will look like the one in the following screenshot:

Our library now allows us to easily add new strategies or new hashing algorithms and use them instantly. We don't have to change any of the existing classes.

trait Sha1Hasher extends Hasher {
  override def hash(data: String): String = new String(Hex.encodeHex(getDigest("SHA-1", data).digest()))
}

trait Sha256Hasher extends Hasher {
  override def hash(data: String): String = new String(Hex.encodeHex(getDigest("SHA-256", data).digest()))
}

trait Md5Hasher extends Hasher {
  override def hash(data: String): String = new String(Hex.encodeHex(getDigest("MD5", data).digest()))
}

abstract class PasswordConverterBase {
  self: Hasher =>
  
  def convert(password: String): String
}

class SimplePasswordConverterScala extends PasswordConverterBase {
  self: Hasher =>
  
  override def convert(password: String): String = hash(password)
} 

class SaltedPasswordConverterScala(salt: String) extends PasswordConverterBase {
  self: Hasher =>
  
  override def convert(password: String): String = hash(s"${salt}:${password}")
}

object ScalaBridgeExample {
  def main(args: Array[String]): Unit = {
    val p1 = new SimplePasswordConverterScala with Sha256Hasher
    val p2 = new SimplePasswordConverterScala with Md5Hasher
    val p3 = new SaltedPasswordConverterScala("8jsdf32T^$%") with Sha1Hasher
    val p4 = new SaltedPasswordConverterScala("8jsdf32T^$%") with Sha256Hasher

    System.out.println(s"'password' in SHA-256 is: ${p1.convert("password")}")
    System.out.println(s"'1234567890' in MD5 is: ${p2.convert("1234567890")}")
    System.out.println(s"'password' in salted SHA-1 is: ${p3.convert("password")}")
    System.out.println(s"'password' in salted SHA-256 is: ${p4.convert("password")}")
  }
}

As we already said, the bridge design pattern is similar to the adapter. Here, however, we apply it when we design our applications. One obvious benefit of using it is that we don't end up with an exponential number of classes in our application, which could make the use and maintenance of the pattern pretty complicated. The separation of hierarchies allows us to independently extend them without affecting the other one.

The bridge design pattern requires us to write some boilerplate. It could complicate the use of the library in terms of which implementation is exactly picked, and it might be a good idea to use the bridge design pattern together with some creational design patterns. All in all, it doesn't have any major drawbacks but the developer should be wise whether to use it or not depending on the current circumstances.