Sandi Metz - 99 Bottles of OOP_ A Practical Guide to Object-Oriented Design¶

Metadata¶

• Author: [[2016]]

Highlights¶

This suggests that you should not reach for abstractions, but instead, you — location: ^ref-61653

Every time the style of the conditionals changes, the reader has to press a mental reset button and start thinking anew. Inconsistent styling makes code harder for humans to parse; it raises costs without providing benefits. — location: ^ref-26789

Incomprehensible conciseness is clearly not the best solution for the 99 Bottles problem. It’s time to examine one that’s more verbose — location: ^ref-32098

Unfortunately, when you name a method after its current implementation, you can never change that internal implementation without ruining the method name — location: ^ref-27179

You should name methods not after what they do, but after what they mean, what they represent in the context of your domain. If you were to ask your customer what "beer" is in the context of the 99 Bottles song, they would not answer "Beer is the beer," they would say something like "Beer is the thing you drink" or "Beer is the beverage — location: ^ref-54025

Naming the method at this slightly higher level of abstraction isolates the code from changes in the implementation details — location: ^ref-25174

None of the solutions shown thus far do very well on the value/cost questions. Incomprehensibly Concise cares only for terseness. Speculatively General tries for extensibility but achieves unwarranted complexity. Concretely Abstract's heart is in the right place but can’t get its feet out of the mud. — location: ^ref-56493

Cyclomatic complexity does not predict application development time nor does it measure programmer productivity. Its desire to identify code that is difficult to test or maintain aims it directly at code quality — location: ^ref-22525

Duplication is useful when it supplies independent, specific examples of a general concept that you don’t yet understand — location: ^ref-45574

In Chapter 28 of Test-Driven Development by Example, Kent Beck describes different ways to make tests pass. Three of his "Green Bar Patterns" are: Fake It ("Til You Make It") Obvious Implementation Triangulate — location: ^ref-19127

Knowledge that one object has about another creates a dependency. Dependencies tie objects together, exacerbating the cost of change. Your goal as a message sender is to incur a limited number of dependencies, and your obligation as a method provider is to inflict few — location: ^ref-45718

The distinction between intention and implementation [… ] allows you to understand a computation first in essence and later, if necessary, in detail — location: ^ref-55817

Therefore, the first step in learning the art of testing is to understand how to write tests that confirm what your code does without any knowledge of how your code does it — location: ^ref-16085

The Shameless Green solution is neither clever nor extensible. Its value lies in the fact that the code is easy to understand, and cheap to write. If nothing ever changes, this solution is quite certainly good enough — location: ^ref-55473