Software Engineering

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.

A machine whose only memory is which state it is in: one table lookup per symbol, accept if it ends on a double ring, then merge the states no word can tell apart.

A regular expression compiles to a machine with one state per letter that runs in many states at once; turning each set of states into one state gives a DFA.

A grammar becomes a program: one method per rule, one token of lookahead per decision, and a tree comes out whose shape is the precedence of the operators.

Run a program by walking its syntax tree: visit a node, evaluate its children, act on their values. The tree is the program, and a loop is the walk coming back to the same node.

Compile the tree once into postfix instructions and run them with a stack: fetch, advance, execute. A loop is a jump backwards, and nothing is matched on its kind again.

Two threads each add one to a counter and the result is wrong, because an increment is three instructions and the scheduler may switch between any two. The bug comes and goes with the timing.

A lock fixes the race and opens a new trap: five philosophers each pick up the left fork and wait forever for the right. Deadlock is a cycle of waits, and every cure makes the cycle impossible.

One thread, no races, and still a timer, a promise, and a file read all in flight: the script runs to its end, microtasks drain, then one task at a time. Order comes from the queues, not the clock.

An actor owns its state and handles messages one at a time: nothing shared, so nothing races or locks. Two workers incrementing a counter get six in any order. The price is a moment nobody can see.

A program is facts and rules; a query is a goal to prove. Resolution picks the first goal, unification matches a clause, backtracking tries the rest: SLD resolution, Prolog's engine, step by step.