Code smells with examples: Bloaters Continued
In the previous blog, we learnt about different types of Code Smells and we also explored one bloater code smell i.e. Long Method in detail. In this post, we will continue the discussion of other code smells of bloaters type with some more examples.
1. Large Class
Many times while programming, we start with some small class like following :
And slowly it gets bigger with every new functionality added ..
And bigger … in short a Mess !
We all end up in this situation unintentionally. The solution is simple but as we discussed last time, we will first find out why this large class is a problem?
Why should Large Class be refactored?
Large classes affect the readability of the program. It gets difficult to maintain such classes over time. But, beyond that, there is one major problem with this one. The class is called a large class when it has more than one responsibility. It breaks the Single Responsibility Principle and as we know there will be more than one reason for which large class can be changed. Particularly, in the example given above, our CustomerService class can be changed if the business logic related to the customer is altered or if the printing logic of the customer gets changed.
As you might have already guessed, the solution to solve this problem is — Extract class. You can extract out the member variables and methods which are responsible for printing, in a separate class, say, CustomerPrinter? :) Depending on the situation, there are some other solutions also. If the class to be separated makes more sense as a subclass, you can extract that class as a subclass. But that will be too much for this post. We will go to another bloater code smell instead.
2. Long Parameters List
Let’s look at the following method :
It has ‘too many’ parameters. (How can I say that? General guidelines say it is ok to have up to 3–4 parameters but beyond that, you should start refactoring) Too many parameters make it not only difficult to read but there is the possibility that sometimes we might forget exactly which parameter is at which place. So we might mix them up easily i.e. while calling the method we can send a phone string instead of an address string and vice versa. It can go unnoticed as both are of the same type. Is it the only problem? No.
What is the deeper problem with this code smell?
The long parameters list doesn’t come alone. It also indicates that we might have other code smells in the code like — Primitive Obsession, Long method and Data clumps. (We will discuss primitive obsession later.) And that means we might not have correctly identified the ‘domain object’ in the system.
Here in this example, the Customer is that object. If we have a Customer class with all the required information i.e. name, address, phone, age etc. and we pass the Customer object to this method, our problem is solved.
Great! We got the solution. This refactoring solution is known as ‘Preserve Whole Object’. If we don’t have this class already, we can create one by grouping the primitive fields in a new class. It is called ‘Introduce Parameter Object’.
3. Primitive Obsession
Primitive Obsession means a lot of use of primitive types like int, string etc. This code smell and long parameter list smell go hand in hand. Primitive Obsession can cause the Long parameter list issue.
It can start with small. Sometimes programmers think that “I just want to add one or two fields, do I need to create a separate class for that ?”. And slowly over time, it keeps increasing. Such primitive fields keep on getting added. The example of the printCustomersBasicData method that we saw in the previous section may have started with a small size. That’s why the same solution — Preserve whole objects — applies to the Primitive Obsession problem also.
Let’s say we have created the Customer class as follows:
But we still haven’t fully solved the problem of primitive obsession. The field gender in the above class can have a set of allowed values in it, for example, male, female or another set of values for the LGBTQ community. But beyond that, it cannot have anything. I mean the gender cannot be ‘XYZ’. So instead of having a string primitive type for storing gender, we can create its class — maybe an enum class — to hold the set of allowed values.
This solution of having a separate class for type code is called — Replace Type code with class.
That’s all from my side for this post. I think we covered a lot about bloaters. In the next post, we will explore another type of code smells — Object-oriented abusers.
Thank you. Your feedback is precious to me.
