Code Smells

Second Chapter

Bloaters

Bloaters are code, methods and classes that have increased to such gargantuan proportions that they are hard to work with. Usually these smells do not crop up right away, rather they accumulate over time as the program evolves (and especially when nobody makes an effort to eradicate them).

1. Long Method
2. Large Class
3. Primitive Obsession
4. Long Parameter List
5. Data Clumps

Large Class

Signs and Symptoms

A class contains many fields/methods/lines of code.

Reasons for the Problem

Classes usually start small. But over time, they get bloated as the program grows.

As is the case with long methods as well, programmers usually find it mentally less taxing to place a new feature in an existing class than to create a new class for the feature.

Treatment

When a class is wearing too many (functional) hats, think about splitting it up:

• Extract Class helps if part of the behavior of the large class can be spun off into a separate component.
• Extract Subclass helps if part of the behavior of the large class can be implemented in different ways or is used in rare cases.
• Extract Interface helps if it’s necessary to have a list of the operations and behaviors that the client can use.

Payoff

• Refactoring of these classes spares developers from needing to remember a large number of attributes for a class.
• In many cases, splitting large classes into parts avoids duplication of code and functionality.

Extract Class

Problem:When one class does the work of two, awkwardness results.

Solution: Instead, create a new class and place the fields and methods responsible for the relevant functionality in it.

Before:

After:

Why Refactor

Classes always start out clear and easy to understand. They do their job and mind their own business as it were, without butting into the work of other classes. But as the program expands, a method is added and then a field... and eventually, some classes are performing more responsibilities than ever envisioned.

Benefits

• This refactoring method will help maintain adherence to the Single Responsibility Principle. The code of your classes will be more obvious and understandable.
• Single-responsibility classes are more reliable and tolerant of changes. For example, say that you have a class responsible for ten different things. When you change this class to make it better for one thing, you risk breaking it for the nine others.

Extract Subclass

Problem:a class has features that are used only in certain cases.

Solution: Create a subclass and use it in these cases.

Before:

After:

Why Refactor

Your main class has methods and fields for implementing a certain rare use case for the class. While the case is rare, the class is responsible for it and it would be wrong to move all the associated fields and methods to an entirely separate class. But they could be moved to a subclass, which is just what we’ll do with the help of this refactoring technique.

Benefits

• Creates a subclass quickly and easily.
• You can create several separate subclasses if your main class is currently implementing more than one such special case.

Extract Interface

Problem:Multiple clients are using the same part of a class interface. Another case: part of the interface in two classes is the same.

Solution: Move this identical portion to its own interface.

Before:

After:

Why Refactor

1. Interfaces are very apropos when classes play special roles in different situations. Use Extract Interface to explicitly indicate which role.
2. Another convenient case arises when you need to describe the operations that a class performs on its server. If it’s planned to eventually allow use of servers of multiple types, all servers must implement the interface.

source of this abstract article is www.refactoring.guru

for read full version or more about benefits and adventures go to under link!