Why Classes Should Not Be Too Long and How to Refactor Overgrown Classes

Why Classes Should Not Be Too Long

In a recent project the author had to modify a class that was 766 lines long and exposed nearly 40 public interfaces, which caused great pain and highlighted the need for refactoring.

“If you have a class with thousands of lines, you must share this article with the author.”

In real projects, overly long classes and classes with too many responsibilities are highly unfriendly.

Usually a class becomes long only when it takes on too many responsibilities or when the developer fails to extract appropriate helper methods or utility classes.

Code quality, especially readability, should be a priority. A quick way to test readability is to ask a colleague who understands the business to read the code and see if they can grasp it quickly.

When the author built a simple RPC framework, most of the time was spent on naming methods, splitting classes, and splitting packages.

Good code should be self‑explanatory without comments; however, achieving this consistently is difficult without code review.

Team consensus on coding standards is essential.

Problems Caused by Overlong Classes

Unreadable – scrolling through thousands of lines takes seconds, and even the original author may lose track.

Hard to extend – many interfaces make extensions cumbersome; a single change can affect thousands of lines.

Redundant Code

“At this point the CV engineer shivers.”

Redundant code (copy‑pasted code) leads to:

Long, non‑concise methods and classes.

Scatter‑shot modifications – every copy‑paste location must be updated.

Too Many Responsibilities

A class exposing dozens of interfaces almost certainly violates the Single Responsibility Principle (SRP). Violating SRP causes:

Design principle breach – a class should do only one thing.

Divergent changes – many callers mean any change forces many other modules to change.

Divergent modifications – many callee methods mean a change propagates widely.

Difficulty extending – subclasses or wrappers must implement all interfaces, making extension painful.

Triggers “testing fury” and “operations fury”.

What to Do When You Already Have Thousands of Lines

Refactor: Extract Redundant Code

Extracting redundant code means moving duplicated code into a separate method, eliminating the need for copy‑paste and allowing a single point of change.

This shortens the original method, makes it clearer, and ensures future modifications happen in one place.

Using IntelliJ IDEA to Extract Redundant Code

1. Locate the duplicated code.

2. Extract method – right‑click → Refactor → Extract → Method (or press Ctrl+Alt+M).

IDEA can detect slight differences (e.g., variable names) and offers to accept signature changes to replace more occurrences.

All 18 duplicate spots can be replaced automatically.

3. Refactor – change method signature.

If the extracted method’s name, parameters, return type, or modifiers are unsatisfactory, use IntelliJ’s Change Signature refactoring (Ctrl+F6) instead of manual edits.

Method names should follow a verb‑noun pattern.

Tom.sweep() ✓

Tom.sweepWithBroom() ✗

Tom.useBroomToSweep() ✗

Refactor: Move Fields and Methods (Transfer Responsibility)

Move fields and methods that do not belong to the current class to a more appropriate class.

Decide who should receive the member and which member to move.

Member A is called twice by class A but only once by the long class, so it should be moved to class A.

Function A is tightly coupled with Member A, so they should move together.

Member B and Function B follow the same rule.

If no existing class fits, extract a new class.

“First decide which field to move, then decide which method to move.”

Using IDEA to Move Fields and Methods

1. Move field – select the field, right‑click → Refactor → Move, then choose the target class.

2. Move method – same steps as moving a field.

Refactor: Extract a New Class

When members and methods have no suitable existing class, create a new class to take over the responsibility.

Using IDEA to Extract a Class

1. Select the fields and methods to extract, then right‑click → Refactor → Extract → Delegate. This creates a delegate (or a Parameter Object / Method Object if only fields or only methods are involved).

“Parameter objects are usually for methods with many parameters; extracting them without usage is wasteful.”

2. Name the new class and choose a package.

Ensure the extracted methods use the extracted fields more often than the remaining methods, adhering to the “cohesion” principle.

If the extracted method directly accesses a private field, first introduce a getter to avoid refactoring failure.

END