Design Principles & Smells

How much do a class's methods have to do with each other? Five published measures answer from the same facts and disagree by design. Run all five on one class and see which failure each catches.

A module should be as abstract as it is depended on. Count the arrows between modules, place each on the instability and abstractness plane, and invert a dependency to move the worst one back.

A method should only talk to its immediate friends. Watch the law judge every call in a small class, see which receivers count as friends, and switch between its object and class forms.

Run a toy program, measure which part takes the steps, and see why speeding one part up by any factor is bounded by the share it had.

A method that keeps growing hides how many paths run through it. Count the decisions and the nesting, then extract a helper and add a guard clause and watch which number falls.

Two methods that open with the same three statements are one clone. Watch a detector find the run, extract it and see the clone survive, then replace the copy with a call.

A method that reads four fields of another class and none of its own belongs over there. Count foreign data, locality, and providers, then move the method and watch the edges turn own.

Three values that always travel together through signatures are an object without a name. Read every signature, find the names that keep company, then give them a class and watch the clump vanish.

A method nobody calls, a field nobody reads, a call after a return. Search from the entry points, list what is never reached, then delete it in cascade order and watch the count fall.

A client asks an object for an object for an object: the train wreck. Count the stranger hops along each spine, then hide a delegate and watch each chain lose a hop.

An order's status is written from three classes, so one change is three edits. Count the classes that touch each field, then move each writer home and watch the spread fall.

One class that draws, saves, and keeps score has three jobs and every caller's attention. Measure its cohesion as connected groups of methods, count who depends on it, then extract a class per job.

Modules that depend on each other in a ring cannot be built, tested, or released apart. Find the rings with Tarjan's walk, then invert one dependency to break each.

A class that constructs its collaborators and names their concrete types is welded to them. Count the classes it is bound to, inject the collaborator, then depend on an abstraction.

Methods that hand values to each other through fields and flags have a flow no reader can follow. Trace writer to field to reader, then pass each value along as a parameter or return.

One query for the list, then one more per row: the cost grows with the data. Count the queries a method sends at N rows, then batch the loop into one query.

Memoizing a method that takes 3% of the run buys nothing and costs clarity. Profile first, flag optimizations in cold methods, then spend the effort on the hot one.