Code Smells Related to Data Management and Object Responsibility

Key Insight

Problematic data management manifests as 'Global Data,' 'Mutable Data,' and 'Primitive Obsession.' 'Global Data' is highly problematic due to its susceptibility to modification from any part of the codebase, leading to difficult-to-trace bugs. The primary defense is Encapsulate Variable (132) to control access and limit scope within a class or module. 'Mutable Data' changes can cause unpredictable consequences and bugs, especially when conditions are rare. Risks are mitigated by encapsulating variables (Encapsulate Variable 132), splitting variables (Split Variable 240), separating pure logic from updates (Slide Statements 223, Extract Function 106), or using Replace Derived Variable with Query (248) for calculable data. 'Primitive Obsession' is the reluctance to define domain-specific types (e.g., money, coordinates), instead using primitive types, leading to potential calculation errors or inconsistent display logic; resolve this with Replace Primitive with Object (174), or Extract Class (182) and Introduce Parameter Object (140) for data clumps.

Object interaction and responsibility issues include 'Message Chains,' 'Middle Man,' 'Large Class,' and 'Temporary Field.' 'Message Chains' occur when a client navigates through multiple objects (e.g., 'object.getA().getB().getOther()'), coupling it to the internal structure and making changes difficult. This can be addressed by Hide Delegate (189) or by extracting and moving functions down the chain (Extract Function 106, Move Function 198). A 'Middle Man' class that mostly delegates calls to another object should be removed (Remove Middle Man 192), with methods inlined (Inline Function 115) or the middle man folded into the real object (Replace Superclass with Delegate 399, Replace Subclass with Delegate 381). A 'Large Class' attempting too many responsibilities, evidenced by numerous fields or extensive code, often fosters duplication and chaos; it should be broken down using Extract Class (182), Extract Superclass (375), or by extracting smaller methods. A 'Temporary Field' is a field set only under specific conditions, causing confusion about an object's state; these variables and their related code should be extracted into a new class (Extract Class 182, Move Function 198), potentially introducing a special case object (Introduce Special Case 289).

Further issues involve 'Divergent Change,' 'Shotgun Surgery,' 'Feature Envy,' and 'Data Class'. 'Divergent Change' means one module changes for unrelated reasons; contexts should be separated using Split Phase (154), Move Function (198), or Extract Class (182). 'Shotgun Surgery' is the inverse: a single change requires many small edits across numerous classes; consolidate changes by moving functions (Move Function 198) and fields (Move Field 207) to a single module, or by combining functions into a class (Combine Functions into Class 144) or transform (Combine Functions into Transform 149). 'Feature Envy' describes a function that interacts more with data or functions in another module than its own; the cure is to move the function to the module containing the data it uses most (Move Function 198). A 'Data Class' is a simple data holder with only fields and accessors; behavior should be moved into it from client classes (Move Function 198) after encapsulating its fields (Encapsulate Record 162) and removing unnecessary setters (Remove Setting Method 331).