Design Pattern : Why You Would Probably Need One
In the software engineering world, we all aim to build a clean, well-defined and structured application, so that our product is reliable, scalable and easy to maintain. But oftentimes in reality we meet or even unconsciously code an app that is so rigid and fragile that even any minor changes made is going to break our app, admit it that we all at least did this twice in our software engineering journey. 💁
“What’s the big fuss? I wrote my own code and i knew exactly what to fix if something is broken”
Some of us may think of the statement above when being challenged on why they write such kind of code, in fact it is true that the one who wrote the code supposed to know what is wrong, but mostly in practice, developers work in teams, which means that you work together with other people to build the app, you have to also consider on how your code could impact the app’s readability & maintainability so that any other team member could easily help you when something went wrong, i’m quite sure you don’t want to make the entire team searching for that one particular bug you caused in the massive haystack of the app. 😜
“Er..Surely no! well then, what can i do about it? How to improve my code quality?”
Alright then, the very first thing you need is of course strengthen your basic knowledge of the language you’re coding with, after that you can use a powerful tool called design pattern to accompany you on your coding journey.
WHAT IS DESIGN PATTERN
Quoted from SourceMaking, a design pattern is defined as below
“A general repeatable solution to a commonly occurring problem in software design. A design pattern isn’t a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.”
In a simpler words, design pattern is a guide, or a concept ( often visualized with diagrams ) that could assist you when code and teach you how to think and build a clear, loosely coupling code.
You might wonder how design pattern could actually help you just like i stated above, consider this case :
Let’s say you are an android developer, and for some reason a data analyst on your team require you to add a feature where you have to send user’s history when they use the app in order to study what module do the users visit the most ( in might seem so weird but this thing actually happen in real life ). A normal developer would probably do this
The developer would create a class and a function to send the log, then somewhere in the code he/she would likely to make an object out of the class and make use of the function created before, just like the code below
“The question is, does it work? YES it is working but does it efficient enough? “
Probably not, because the logging method uses the same class, which in this case the Logger class, if there is 10 menus or modules in the app, then the developer should have at least 10 Logger objects, which is not the best practices ( although it works ) since they are all doing the same thing and surely 10 objects is consuming more space in memory than a single object, then what can we do about it?
We can do something about it! we can make use of the singleton design pattern which suits this problem the most.
Singleton’s definition on the software engineering world is just the same with those in English, which is a single entity. The purpose of singleton, as quoted from SourceMaking is
- Ensure a class has only one instance, and provide a global point of access to it.
- Encapsulated “just-in-time initialization” or “initialization on first use”.
The essence of Singleton is just, you can limit the number of object initialization down to a single object and reuse the object all over the code without having to instantiate another one just like the example code above. Seems handy right?
Let’s see how we can implement it on our code, to make it more effective and neat, consider this code :
We need a little extra effort in our class to make it singleton, here’s the play by play :
- We made a class named Logger
- We then create a companion object of the class. In Kotlin, if you want to write a function or any member of the class that can be called without having the instance of the class then you can write the same as a member of a companion object inside the class. So, by declaring the companion object, you can access the members of the class by class name only (which is without explicitly creating the instance of the class). You can read more about companion object here ( Companion Object )
- Inside the companion object, we declare an attribute named instance, which will be our singleton object
- Starting on line 6, we made a getInstance getter, where it would return an instance of our Logger class, but firstly it checked whether our instance attribute is already instantiated or not, if it is null ( have not been instantiated ), then the instance get assigned a new object of our Logger class module, the assignment will only happen on the first time the getter is called, because the next time the getter is called, it will just return the already instantiated object before.
We then could call our singleton class like such
And voila 🎊🎊, our first design pattern implementation!
Notice on the code that we do not call any object instantiation because it is already handled on our singleton class, how neat is that 💌, and by using singleton, you are guaranteed that only one Logger instance is being used and no more unnecessary instantiation!
Kotlin also provide a handy feature if you want to make a singleton class, instead of using companion object, you can just change the class keyword into object ( notice that this keyword has a lower case of ‘o’ ), for example :
Then you could just call it like this
Even neater and concise right? ;D
Base on the examples given above, we could see that design pattern provides a solution to problems we might meet when building an app, which can result in a cleaner or a more efficient code. Besides singleton, there is a ton more design patterns waiting for you to explore, i personally would recommended learning from the SourceMaking website, since they cover almost every design patterns out there!
Using design patterns, you could train yourself on how to build a much more effective code, and learn the best practice on how to solve problems that you might meet during your journey, but keep in mind don’t overuse design patterns, you have to consider several factors before deciding to implement one, here’s a good article telling you when to decide to not use a design pattern.
Don’t Get Obsessed With Design Patterns
Design patterns can be our best ally when used correctly. However, when used in the wrong place, they can do more harm…
That’s all folks.
Happy Coding 🎊