A type — class or interface — with too many fields and methods; multiple unrelated responsibilities under one name.
Each type has one cohesive purpose; methods cluster around fields they actually use.
Smellier version
class Order {// lineItems, totals, customer info, shipping address, audit log, ...}
Fresher version
class Order { /* lineItems, totals */ }class Customer { /* name, email */ }class Shipping { /* address, track */ }
Cognitive load: every reader pays for fields they don't care about; merge conflicts spike; testing is unfocused.
Splitting a large type creates collaborator relationships that the team must learn; some types are large because they encode a genuinely large domain concept that resists decomposition.
Smaller, more testable units; clearer ownership; faster reading.
Splitting every large class on superficial groupings (methods that happen to share a prefix, fields that happen to be related) without honoring real cohesion boundaries — produces fragments that don't make sense apart.