The previous two articles, “Identifying Bad Code Smells (PART 1)” and “Identifying Bad Code Smells (Part 2),” covered 18 code bad smells. Four more bad code smells were covered in Refactoring, and the remaining four are covered in detail in this article.

These four code bad smells are:

  1. The Middle Man
  2. Inappropriate intimacy
  3. Imperfect library classes
  4. A rejected bequest

01 Middle Man

In my previous article, “Identifying bad Smells in Code (II),” the code smell of the Middle Man was mentioned in “Over-coupled message chains.” What kind of code is the Middle Man?

Middleman refers to code that overuses delegates. Refactoring gives a reference to the idea that if half of a class’s methods are delegated to other objects,

Why are middlemen a bad code smell?

Overuse of delegates. This means that when some requirement changes, the middleman class is always involved. The more man-in-the-middle code there is, the more time is wasted.

How to solve the bad code smell of middlemen?

Middleman code lies in overuse and delegation. The solution to the bad taste of middlemen is to reduce delegation:

To Remove the middleman, use the Remove Middle Man refactoring technique.

Of course, if the original code does not change much in the proxy class, you can also choose to delay the refactoring, according to the principle of “three things, three refactoring” can choose when the change occurs.

02 Voluptuousness, Inappropriate Intimacy

This is when classes spend too much time exploring each other’s private properties or methods.

Voluptuousness may be caused by:

  1. The two classes should never have been separated;

  2. There is a bidirectional association between the two classes;

  3. Because inheritance leads to intimacy;

    .

Why is intimacy a bad taste of code?

  1. Voluptuousness leads to strong coupling;
  2. And the responsibilities between classes will become blurred;
  3. Access to each other’s private information leads to too many operations, or to encapsulation compromises that make the two classes entangled.

How to solve the bad taste of approbity code?

  1. Use Move Fields and Move methods to Move properties and methods to where they should be.
  2. If moving properties and methods directly is not appropriate, try using Extract Class to see if you can find a common Class.
  3. If the problem is caused by mutual calls, try changing Bidirectional Association to Unidirectional to separate the Association.
  4. If inheritance leads to intimacy, try removing the inheritance and using proxy classes instead.

03 Imperfect library classes

When using third-party libraries directly, the code becomes less readable and the intent is not clear.

Why are imperfect library classes a bad taste of code?

Third-party libraries provide functionality that can be reused in many scenarios. However, in a business scenario, it is always necessary to switch from a business perspective to a purely technical perspective to use some third-party class library.

For example,

Date newStart = new Date(
  									previousEnd.getYear(), 
  									previousEnd.getMonth(), 
  									previousEnd.getDate() + 1);
Copy the code

It’s not easy to see what this means at first glance. An imperfect library is the result of poor semantics in your code.

How to solve the bad code smell of imperfect library classes?

Many developers use comments to make code readable, but such comments are a bad taste of code. However, you can use the function name to reveal the intent.

So in the case of the above example, you can use Extract Method to Extract a function and generate the following code

Date newStart = nextDay(previousEnd); .private Date nextDay(Date previousEnd) {
		return new Date(
							previousEnd.getYear(), 
							previousEnd.getMonth(), 
							previousEnd.getDate() + 1); 
}
Copy the code

Where nextDay() is called, it is easy to know the date next to the previousEnd date.

If there are multiple such calls in a class, or if there are similar functions in multiple classes, extracting a single class and providing these methods through that class is a clear way to eliminate duplication and improve reuse. This class can be implemented either by proxy or inheritance. If a class provides only proxy methods, the implementation is delegated to the class library. In this case, it is better to use subclasses generated by inheritance and add methods to them that can be reused. The refactoring process can be described in Introduce Local Extension.

It’s obvious that third-party libraries are often designed with good intentions, but when it comes time to enjoy the quick implementation, you need to be aware of the bad taste that third-party libraries bring to your current project and work on fixing those problems.

04 Rejected bequest

This bad taste refers to the situation in which methods of the parent class are forced to be inherited from the base class when the subclass does not need them. There are two common causes of this bad taste:

  1. The inheritance system is not well designed and needs to be adjusted.
  2. The base class implements an interface, causing subclasses to implement methods that correspond to that interface when they don’t need them.

For a detailed example, see Refactoring Analysis 21: Refused Bequest.

Why rejecting a legacy is a bad taste of code?

The bad taste the main reason is the inheritance of bad taste, subclasses are forced to implement some methods or the parent class method on themselves did not help even misleading, such as: the code through inheritance square inherit rectangle area and example, interested can refer to, practice the mode of agile software development principles, the magnitude of the substitution principle.

How to solve this code bad taste of rejected bequests?

There are two ideas:

  1. Improve the inheritance system. Remove methods that are not needed by a subclass and create a sibling of the subclass. Use Move Method to Move methods that are not needed to the sibling class. Use Move Field to Move non-public attributes involved to the sibling class.

  2. Use proxies instead of inheritance. This type of modification only involves subclass adjustments, has a small impact, and does not result in new concepts for maintaining inheritance like the first refactoring method. It also prevents subclasses from being forced to implement methods because the base class inherits an interface.

conclusion

At this point, 22 common code bad smells have been described. A focus on tools, frameworks, and some focus on code quality can allow a project to evolve over time. Of course, there are often more than 22 bad smells in the workplace.

In the project, we can use Check Style, PMD and Arch Unit to help us timely find the problems in the project, but the “soft” part requires us to spend energy to understand clearly what is, why and how to solve it.

As you’ve probably already noticed, a lot of bad taste comes from not being able to respond quickly to change, either because of code design or readability. Even bad code smell can be divided into strong bad smell and light bad smell, so the principle of refactoring is “refactor after three”, so when faced with bad code smell, if the code smell is weak, we can delay eliminating the bad smell. If the bad taste is already strong, or if the subtle bad taste is too frequent to be effective, it is better to address the bad taste first.

extension

Refactoring doesn’t happen at the end of the project, it happens on a day-to-day basis. Using TDD (test-driven development) is a good choice. If you are familiar with TDD and testing tools, TDD will not slow you down but lead to more rigorous thinking and higher quality code implementation. If you are interested, please refer to:

TDD Combat (1) : Experience

TDD Combat (2) : Tasking To Action

TDD In Action (3) : Simple Design

reference

“Refactoring”