Refactoring and Design Pattern
Power of communication
Last semester, we were first introduced to the world of design pattern and refactoring. We learned about many common design pattern for each of the category, and we also learn how to refactor our code. A very interesting course I must say, would recommend everyone to try to learn it. Now that we are working on multiple project for different courses, the more I realize the importance of design pattern and refactoring.
Design Pattern
When developing our code, we will, at some point, encounter a problem. There is a high chance that the problem that we encounter is already solved by other developer. When a problem is encountered a lot, a pattern will eventually recognized by some people, these pattern will then be a design pattern.
Design patterns are typical solutions to commonly occurring problems in software design. They are like pre-made blueprints that you can customize to solve a recurring design problem in your code. — refactoring guru
When to use it
Whenever you can, whenever your problem suited the pattern. All design pattern is a best practice, hence why it is better to use it whenever applicable. Using a design pattern in your code will ease your development cycle. I forgot where did I read this but I’ve read that most important thing about design pattern is the power of communication, not just the fact that it solve your problem. Imagine when you are working with other developer. When you use a pattern in one of your code, you can just say to that dev that you use a pattern, that dev should understand what do you mean easily.
The patterns
There are many recognized patterns, even when I learn about design pattern, we only cover like half of the most common one. Also, due to the nature of our current project, UKM Indonesia, a website that use serverless Angular, we don’t use that many patterns. So I’ll talk about some patterns that we do use and also some that I’ve already learned.
Singleton
A singleton, just like it’s name, is a pattern where an object has only one instance of itself. This pattern is useful when you want to have only one instance of an object, be it for data integrity purpose or any other needs. Singleton is useful when you have multiple object that access an object. Instantiating that object many times can come at a cost. By using singleton pattern, we only need to instantiate the object only once. The way singleton works is that usually, the object will have a static method that can be called without instantiating the class first. That method will check whether an instance of that class is exist or not, if no then create one, then return. If an instance is exist however, it would return that instance immediately. Here is an example of a singleton class in Java.
Dependency Injection
One of the pattern that I learned by programming is the dependency injection. I first tried this pattern when I was developing a Spring Boot app. When our application get bigger and bigger, it’ll become a hassle when a class or a service require many dependencies. We will need to instantiate all those dependencies. There is a couple downside of this like the fact that to some degree, you need to know how the dependency work. That means that if that a dependency require another dependency, we also need to instantiate them.
Dependency injection help with, well, inject the dependency. There is an object that is called an injector that will scan all injectable object and also all object that needs to be injected. It will then inject those injectable whenever the object is instantiated. In this project we use Angular which does implement dependency injection. Here is how we use it.
Here I have an authentication service and a component that needs it. I can just declare the class that I want to be injected in the constructor. The internal of Angular will handle the injection. Then when I need the instance, I can just reference it. The way I declared that SignUpComponent need the service is by declaring it in the constructor argument. This is called a constructor injection. There are two other method to inject which is method injection and property injection.
Facade
One of the library we use in this project is Amplfy CLI. It is a framework that abstract most of AWS’s services. One of the feature of the CLI is that you can generate the entire GraphQL schema in AppSync into a service. The downside of this is that the service contains thousands of lines (at least ours). Developers that doesn’t involved in building the AppSycn API won’t understand the code. So I tried to create a service that helps front-end people using the API so that they can spend more time creating a beautiful website.
Unfortunately, we ditched AWS. So here an unfinished example of facade pattern.
Our content object is created by UKM’s developer. It is quite weird I must say, but let just ignore it. There is a content table, a table containing the data for that object, and a few attributes table. The code snippet above only get the content and the data because again, it is an unfinished code. By abstracting the API, other developer don’t need to worry about the structure of the API. By using Facade pattern, we also decouple the front-end with the library, thus improving maintainability.
Refactoring
I already created a blog about clean code and refactoring, it is an activity that does not change the code algorithm and design but instead, it improves the cleanliness of the code. Refactoring is an important cycle in software development. Without it, it is hard to maintain our code.
We do refactoring after we finish making our code passed the RED TDD cycle. If we found part of the code that can be improved by applying design pattern or generally better algorithm, we also do refactoring.
Conc
That is all for now. There are many other patterns that I need to learn. If you are interested on learning more, try seeing my code for last semester’s courses where we learn about design pattern, clean code, and refactoring, Advanced Programming.
Thank you for reading.
