- Published on
Learning Design Pattern: Adapter Pattern - The Adaptable are Successful
- Authors
- Name
- Dan Tech
- @dan_0xff
The Adapter Pattern is not just a common Design Pattern. It's a mindset that helps us live and thrive in this ever-changing world.
The Age-Old Problem Of Devs: Reinventing The Wheel
Hey Dev Brothers! Have you ever felt helpless when having to reinvent the wheel just because the available frameworks don't work well together?
Instead of wasting time and effort rewriting code from scratch, we Devs can absolutely use the Adapter Pattern to transform incompatible modules or frameworks into close, like-minded friends for our product. This both shortens development time, ensures the stability of the old system, and will definitely help you gain more new lessons about product development :)
Real-World Example With Adapter Pattern
Suppose you have an old but usable Binary File encryption library, developed on an Interface that is incompatible with the software you are writing. Our new software requires a standard Interface according to the design, allowing easy change of encryption algorithms in the future.
class FrameworkBinaryHelper {
fun encryptBinary(input: ByteArray, key: ByteArray): ByteArray {
println("encryp binary by framework...")
return input // Demo value
}
fun decryptBinary(input: ByteArray, key: ByteArray): ByteArray {
println("decrypt binary by framework...")
return input // Demo value
}
}
interface BinaryFileProcessor {
fun process(input: ByteArray, key: ByteArray, operation: Operation): ByteArray
}
enum class Operation { ENCRYPT, DECRYPT }
The problem arises that we cannot directly embed FrameworkBinaryHelper into the project.
The only solution at this point is the Adapter Pattern!
class BinaryFileProcessorAdapter(private val legacyEncryptor: FrameworkBinaryHelper) : BinaryFileProcessor {
override fun process(input: ByteArray, key: ByteArray, operation: Operation): ByteArray {
return when (operation) {
Operation.ENCRYPT -> legacyEncryptor.encryptBinary(input, key)
Operation.DECRYPT -> legacyEncryptor.decryptBinary(input, key)
}
}
}
With the Adapter Pattern, we create the BinaryFileProcessorAdapter class to bridge the gap between the two Interfaces, allowing them to work together without changing the original code.
It is true that THE ADAPTABLE ARE SUCCESSFUL.
If you demand to rewrite the BinaryHelper, the Manager will probably hold an internal meeting and then tell HR not to extend the contract because this guy is so annoying. That's it. HEHE
Invaluable Lesson: Why Using Adapter Pattern Is Adaptable?
Dear Dev Brothers, in this rapidly changing technology world, "adaptation" is a vital element. The Adapter Pattern is not only a Design Pattern but also a guiding principle for you to maintain your job position. There is no other way, only to be Compatible with change.
But to be compatible, we cannot discard everything we have and relearn from scratch. We must know how to take advantage of what is available, Wrap it with a new layer, and provide the market with what they need.
I'll leave a few bullet points here, read through them and apply them:
- RECYCLE Old Code: Instead of tearing down and rebuilding, we should transform old code into new code, saving time and effort. Like upgrading a classic car into a modern car, retaining historical value while meeting current needs. And most importantly, providing stable, fast, and powerful solutions to the market.
- INTEGRATE With External Systems: When integrating with third-party systems or APIs, we often encounter language incompatibility issues. The thinking of the Adapter Pattern helps us create joints between systems, helping them cooperate smoothly.
- FLEXIBLE Expansion: When requirements change, we need to use our skills to change the Adapter without affecting the original code. This skill makes our code more flexible and maintainable, like changing the weapon type for a warrior, helping him adapt to any battlefield.
Good luck, brothers!
@dantech