Refactoring Thoughts [1]: Single POJO per layer
Most of the times we use POJOs to transfer data between different layers of our applications or the network. Shall we use the same POJO for each layer of our applications?
Let’s say that we have an Android application which fetches data from a dog shelter API and shows the cute pets to the user. Dog shelter has this POJO:
We have 2 options. You could move this POJO across our application or we can create a new POJO for each layer. If we use the same POJOs across our application we:
- Achieve faster implementation/development time
- Save some memory
- Improve performance due to less operations and memory allocation.
But if we design our application with different POJO for each layer we:
- Separate the application layers much better
- Make our modules (if we use) reusable for much different scenarios
- Make our module/package/class behave like a big function with POJO A as input and POJO B as output
- Improve the single responsibility for our classes
Actually all of the above belong to the same techniques. They could be mentioned under one single dash, “Clean Code”!
A quick thought would be to use 1st option but we should consider if this solution is good for the “developers of the future” and easily expandable.
So, we will implement this example using the option No 2 and we hope that we are doing the right thing. We will continue with this implementation for POJOs:
These are our models. They are simple POJOs so they cannot convert themselves from one POJO into another, that’s why you are going to need 2 Mapper classes to map one into another. We are going to follow the POJO design pattern as it is designed and we should not put any logic into them.
Global changes are here
Our application is ready and it is published. We receive some comments from our users which say that they would like to see some specs about these dogs. It is very important for them to see the height and weight of each dog.
It is time for some changes:
Our POJO inside the application should be transformed as well:
Although it is absolutely normal to modify all of our POJOs because the change affects all the layers I started to think that we have done a lot of work. It seems that the decision to continue with the 2nd option is bad because we have to make changes to 3 POJOs and 2 Mappers. We are feeling weird. Does clean code worth it? I was thinking of this for the next days.
UI changes have arrived
While I was thinking about our implementation I saw some new comments that say “Home screen has a lot of data”, “I scroll a lot to see all the dogs”, “I wish I could expand/collapse that extra specs per dog”. We have to add this feature as well and we enjoyed the changes very much! Here are the new POJOs:
We just need one variable for UI POJO. The code is so clean! Imagine the mess of implementing this feature for 1st option. It seems that clean code pays off after all. But, is this all it can give back to us? I would expect more…
API changes have come…again
After a couple of months a new e-mail arrived. Obviously more than one arrived during this period but I don’t need to mention the others!
It was from the shelter. They would like to change the JSON and here we have our new POJO:
We have already similar POJO and we were very happy. But what was that “order”? They wanted the dogs to be displayed with ascending order based on this “order” property! Sometimes the younger dogs were displayed before the older ones so we had to apply some ordering. Sounds fair! Let’s see the changes at our POJOs:
Wait, what?! We don’t need to touch a single line of code in the UI layer. We just add this order property to the logic layer, sort the list based on this and we are ready to go!
The UI POJO should not know anything about ordering just like the network layer should not know anything about expand/collapse state. Less code to write means less bug to debug!
You should not feel bad about a couple of CPU cycles spent for converting one POJO to another because clean code worth it.
Rules
- Your output should be different from the input. Just imagine a
voidmethod which modifies the parameter instead of returning something new. It feels the same! Yes, I am talking to you! - Separation of concerns should be taken under consideration every single time. You cannot achieve separation of concerns by working on a single model. You will have a hidden, bad dependency.
Now you are ready to put some cats with the dogs and have these animals live in peach!
The end
Don’t you want to end it so soon? See other refactoring articles of mine, here!
