99 Bottles of OOP

Alignment - Steer towards the average heading of neighbors

Separation - Don’t get too close to a neighbor

Cohesion - Steer towards the average position of the flock

, if you rearrange code without changing behavior and tests begin to fail, then the tests themselves are flawed. Tests that make assertions about how things are done, rather than what actually happens, are the prime contributors to this predicament.

The "open" principle says that you should not conflate the process of moving code around, of refactoring, with the act of adding new features. You should instead separate these two operations. When faced with a new requirement, first rearrange the existing code such that it’s open to the new feature, and once that’s complete, then add the new code.

Single Responsibility
The methods in a class should be cohesive around a single purpose.

O - Open-Closed
Objects should be open for extension, but closed for modification.

L - Liskov Substitution
Subclasses should be substitutable for their superclasses.

I - Interface Segregation
Objects should not be forced to depend on methods they don’t use.

D - Dependency Inversion
Depend on abstractions, not on concretions.

Tests are not the place for abstractions—they are the place for concretions. Abstractions belong in code.

Does the change I’m contemplating make the code harder to understand?
When abstractions are correct, code is easy to understand. Be suspicious of any change that muddies the waters; this suggests an insufficient understanding of the problem.

What is the future cost of doing nothing now?
Some changes cost the same regardless of whether you make them now or delay them until later. If it doesn’t increase your costs, delay making changes. The day may never come when you’re forced to make the change, or time may provide better information about what the change should be. Either way, waiting saves you money.

When will the future arrive, i.e. how soon will I get more information?
If you’re in the middle of writing a test suite, better information is as close as the next test. Squeezing all duplication out at the end of every test is not necessary. It’s perfectly reasonable to tolerate a bit of duplication across several tests, hoping that coding up a number of slightly duplicative examples will reveal the correct abstraction. It’s better to tolerate duplication than to anticipate the wrong abstraction.

Code like this pluralize method gets written when programmers take the DRY principle to extremes, as if they’re allergic to duplication

as tests get more specific, code should become more generic. Code becomes more generic by becoming more abstract. One way to make code more abstract is to DRY it out, that

Write a test.
Because the code does not yet exist, this test fails. Test runners usually display failing tests in red.

Make it run.
Write the code to make the test pass. Test runners commonly display passing tests in green.

Make it right.
Each time you return to green, you can refactor any code into a better shape, confident that it remains correct if the tests continue to pass.

Assignments is a count of variable assignments.

Branches counts not branches of an if statement (as one could forgivably infer) but branches of control, i.e., it counts function calls or message sends.

Conditions counts conditional logic.