Small method

As explained in Simple Object-Oriented Design: Create clean, maintainable applications

A small code unit is a method or class deliberately limited in size and scope to reduce implementation complexity.

A small method is a deliberately limited, cohesive unit of behavior. Keeping methods and classes small is a primary way to control complexity as code evolves: oversized units are harder to read, change, test, and extend, and they invite bugs because developers cannot easily grasp all their paths and cases. section 1.2.1 section 2.0

Size is not merely a line-count target. A method should do a clear, nameable action with requirements that are easy to see. When a segment inside a long method has its own purpose, extract it into a private method; keep it private when it is an implementation detail rather than behavior for other classes to invoke. section 2.1.1

Extract one cohesive action

Start with a public method that mixes several actions: validate input, calculate a result, and persist it. Move one meaningful segment at a time into helpers such as validateRequest(), calculateTotal(), and saveOrder(). The public method then communicates the overall flow, while each helper can be understood independently. Test private helpers through the public method; if isolated testing becomes necessary, move that behavior into another class. section 2.1.1 section 2.5

Use small methods and classes to make change safer, but avoid splitting mechanically:

• Read less implementation at a time; follow calls only when their details matter. section 2.1
• Replace or extend modeled pieces independently, and choose between isolated tests and tests of the assembled behavior. section 2.1
• Break multistep business flows into cohesive steps, using simpler workflow mechanisms unless flexibility or cross-service execution demands more. section 2.3.2
• Keep related code together when separation creates awkward signatures, offers little testing or replacement value, or leaves only a few helpers. Too many microclasses can also harm maintainability. section 2.1.3
• Treat dependency count as another dimension of size: a class with many dependencies may need to be broken down, while a new linked class can add coupling. section 4.3

Figure 1.2 Simple code becomes complex over time and, consequently, very hard to maintain.

Use the figure as a reminder that code tends to grow more complex over time unless its size is actively managed. section 1.2.1

Smallness supports cohesion but does not replace judgment about responsibility. The Single Responsibility Principle asks whether a unit has one reason to change; reducing size often makes that responsibility easier to see. Move new complexity away from stable units when adding features, rather than continually enlarging an existing method or class. section 2.3.2 section 2.5

How Simple Object-Oriented Design: Create clean, maintainable applications covers it

How deep it goes

Gives extraction criteria, private-method testing guidance, flow decomposition, and exceptions; defers event-based workflow implementation details.

Examples

Uses long methods, oversized classes, private-method extraction, and multistep business flows as concrete refactoring situations.

What it assumes

Assumes familiarity with classes, methods, access visibility, and unit tests while teaching method extraction from first principles.

What you can do after

Evaluate/understand it by identifying cohesive extraction candidates and balancing simpler units against excessive fragmentation.

How it connects

Connects small methods to cohesion, the Single Responsibility Principle, unit testing, dependencies, Chain of Responsibility, Decorator, and Observer.

liveBookmanning.com

Read Simple Object-Oriented Design: Create clean, maintainable applications on liveBook Get the book at manning.com

Related concepts

• workflowused by · A workflow is an organized sequence of coordinated activities, tasks, or decisions through which work progresses toward an outcome.
• complexityaddresses · Complexity is the degree of difficulty in understanding, analyzing, changing, or operating a system or problem, arising from its structure, behavior, or interacting parts.
• testabilityproduces · Testability is the degree to which a system’s behavior can be exercised and evaluated effectively, efficiently, and reliably through testing.
• maintainabilityproduces · Maintainability is the degree to which software can be understood, modified, corrected, tested, repaired, or kept operational with reasonable effort over time.
• extensibilityproduces · Extensibility is the capacity of a software system to accommodate additional capabilities or behaviors with limited changes to its existing structure.
• functionkind of · A function is a callable program unit that performs an operation, may accept inputs, and can produce a result or side effect.

This explainer was generated by Manning's knowledge graph from the text of Simple Object-Oriented Design: Create clean, maintainable applications. The section links point to the parts of the book it draws on.