Refactoring

Change internal software structure while preserving its specified observable behavior. Extracting a coherent operation into a named method or moving a responsibility behind an interface can improve clarity without changing results. Regression tests provide evidence of preservation, while contracts and invariants supply stronger reasoning about the changed structure.

An observable feature of source code suggesting a possible underlying design problem. It prompts investigation rather than proving a defect. Duplicate code, feature envy and a long method suggest potential transformations, and context can justify leaving an apparent smell unchanged.^[ref]

An operation depends heavily on another object's data or responsibilities. Moving the operation, or the relevant coherent part, to that object's abstraction can reduce exposed internals and misplaced coupling. The appropriate home follows responsibility and behavior, not merely the number of field references.^[ref]

A method whose size or mixture of responsibilities makes its purpose and structure difficult to follow. Extract meaningful steps with clear interfaces, preserving behavior. A fixed line-count threshold is not a proof of poor design; the useful question is whether the method hides coherent separable responsibilities.

Multiple fragments may encode the same decision or responsibility, increasing the risk that a later correction reaches only one copy. A shared operation or component can consolidate genuinely shared knowledge. Independent concepts that merely look similar should not be forced into a common abstraction prematurely.