Architecture & design · Book notes
Sandi Metz's 99 Bottles of OOP and knowing when to stop
Sandi Metz's 99 Bottles of OOP spends a whole book refactoring one beer-song program, starting from a plain version called Shameless Green that already works for a problem this size.
I just find myself thinking, geez Louise, you are complicating this simple problem like crazy, because then you start getting into things like, well, why are we hard coding bottle, because it might not always be bottles. It might be a flask. It might be a jug.
This is 99 Bottles of OOP by Sandi Metz and her co-authors Katrina Owen and TJ Stankus. The whole book is basically one extended refactoring of a single program that prints out the “99 Bottles of Beer” song.
One of the best pages early in the book is where they show the Shameless Green.. the straightforward version with a case statement and the verses. It doesn’t look very exciting, but it’s easy for anyone to read. It’s the right answer for a problem of this size, and the book makes sure to demonstrate that before going on to argue why we should go beyond it.
If you literally just need down and dirty, this was what’s been asked of you, Shameless Green is the correct answer, and I do agree with that.
But the book doesn’t stop there. It then goes on to talk about how you can avoid using conditionals by using the Liskov Substitution Principle, and it deconstructs the plain version of the song to make it adhere to this rule, even though it never needed to in the first place.
There’s a pathological avoidance of conditionals in this code. And again, this is an ideological thing.
I think this is where ideological zealotry can get you really twisted up into knots. A principle should serve its purpose. If a principle stops serving its purpose and it’s just a way for you to take what you’re doing and defend it without additional thought, I think you end up getting into these weird spots.
The weird thing about this is that Metz wrote an essay called The Wrong Abstraction where she talks about how duplication is way cheaper than the wrong abstraction. And getting ready to sing a song about beer for the day when a bottle becomes a jug is basically as clear an example of the wrong abstraction as I can imagine.
I think my last criticism is this book is missing the when to stop lesson, which is that just because I could doesn’t mean I should.
The back of the book promises that I’ll learn to recognize when code is “good enough”. But what would the stop sign look like in a code review?