Refactoring - What problem on your code do you want to fix?
Tags: refactor, productivity, practices, books
Published: 2019-11-09 15:42:35

---
title: Refactoring - What problem on your code do you want to fix?
published: true
description: When I started to learn about refactoring, I found the name of the patterns very unclear, so I made a dictionary to identify which pattern based on the problem we have
cover_image: https://rachc.dev/images/refactoring00.jpg
tags: Refactor, productivity, practices, books
---

When we start to study refactor techniques, we came across several (anti)patterns that we can find in our code. Many of these patterns have names that aren't very clear and, at first sight, is hard to understand what they are.

Having this difficulty, I decided to create a guide to identify which patterns are according to the pain that we feel when we are viewing the code.

## 1. Code that has grown way more than they should (Bloater)
1. **The same group of data is repeated in several different places** = Data Clump
2. **There are too many primitives, a lot of constants or primitives that should be an object** = Primitive Obsessions
3. **Methods that are too long** = Long Method
4. **Classes that are too large** = Large class
5. **We have way too many parameters** = Long parameter list

## 2. Problems arising for misuse of object-orientation (Object-Orientation Abusers)
1. **A lot of ifs/switch case** = Switch Statement
2. **Temp Variable** = Temporary Field
3. **Two classes with the same function but different names** = Alternative Classes with Different Interfaces
4. **My child class uses very little of the father class** = Refused Bequest

## 3. Problems that make any code change way too hard, because we have to modify several different places to change something(Change Preventers)
1. **To make a simple change, I need to go through several different methods in a class** = Divergent Change
2. **In order to change something, I need to go through several different places in different classes** = Shotgun Surgery
3. **If I need to create a child class for class X, I also need to create a child class for class Y** = Parallel Inheritance Hierarchies

## 4. There is a lot of useless stuff in there. Their presence only difficult the code understanding (Dispensable)
1. **Duplicate code**  = Duplicate code (duh)
2. **There is a class that doesn't do anything** = Lazy Class
3. **The piece of code was created thinking about the future (that probably never came)** = Speculative Generality
4. **I have a class that is a bunch of getters and setters, and it exists only to be manipulated. Probably it serves only to be a database interface** = Data Class
5. **Comments** = Comments (duh2)

## 5. The classes are too close. They are dependent on each other, and there is a lot of coupling (Coupling)
1. **Methods that access a lot of gets of another object** = Feature Envy
2. **Object that calls another object that calls another object that calls anot...** = Message Chains
3. **A class acts only as an intermediary for another** = Middle man
4. **A class use methods and fields of another class** = Inappropriate Intimacy
5. **I Installed a lib that doesn't do everything that I need** = Incomplete Library Class

These patterns only identify what to look when we want to refactor. For every pattern there is a recipe to fix that. You can find all [in this website](https://refactoring.guru/refactoring/smells)

If you want to/can invest a little more, I advise you to buy the "refactoring" book, because they have (waaaaay) more examples than the website mentioned above, and is a good source for consultation.

----

*imagem do post de [Alex Andrews](https://unsplash.com/@alex_andrews)*