Among competing hypotheses, the one with the fewest assumptions should be selected.
This isn’t exactly a new idea. Actually, one could think of it as a 700 year old programming technique.
Consider two approaches. One method requires you to specify a lot of dependencies. Methods have over seven parameters. Complex machinations occur, requiring all of the objects to be “just so” in order to function. The class assumes that everything is perfect. Unfortunately, this class also has many reasons to change. When any of its dependent parts changes, the class needs to be rebuilt, possibly re-engineered. This makes the code rather fragile, leading to major support issues in the future.
In the second approach, classes and methods are kept small and simple. The number of dependencies is kept to a minimum. Since each method has only one job, it only has one reason to change. With fewer dependencies, the methods are easier to test.
Simpler is generally better. A class that makes fewer assumptions is more testable.
Today's Card 