Refactoring - What problem on your code do you want to fix?

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

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

Comments

[Mustapha Belmokhtar]

That's a good article to read.. Refactoring becomes a must

[Rachel Curioso :D]

Yes! It's very difficult not work with legacy code. Sooner or latter you will feel the need to refactor!

[Eljay-Adobe]

"Problems arising for misuse of object-orientation (Object-Orientation Abusers)"

I call that Abject-Oriented Programming. ;-)

I like this post. One shortcoming in our industry is the difficulty in refactoring.

Most programming languages are not refactoring friendly. (I'm looking at you, C++!)

Tooling is often leaves much to be be desired -- the tools that are good at refactoring are such a breath of fresh air that they make quite a splash. Eclipse and Java; JetBrains IntelliJ with Java, Resharper for C#, and all the other amazing tools JetBrains has developed.

[Mik Seljamaa 🇪🇪]

Their presence only difficult the code understanding
Should be:
Their presence makes understanding the code only more difficult.

[Mik Seljamaa 🇪🇪]

Or " even more difficult."