99 Bottles of OOP

After reading 99 Bottles of OOP by Sandi Metz, I’ve gained valuable insights into writing clean and efficient code. The book challenged my understanding of how to keep objects focused solely on their own responsibilities and not on the responsibilities of others. While the lessons might not apply universally, the perspective I’ve gained is incredibly worthwhile.

Until now, I hadn’t paid much attention to the metrics Rubocop uses to evaluate my code. My primary concern was whether it flagged something and whether I needed to fix it. This book, however, helped me understand common coding metrics, why they were created, and how they assist developers. Rules about method calls or variable assignments are straightforward, but the metric that stood out most was the Liskov Substitution Principle.

This principle states that subclasses must be substitutable for their parent class. In simpler terms, subclasses must be compatible with their parent class and with each other. For example, an airplane model should not subclass a car model. While both might have engines and tires, they are functionally very different. Proper use of this principle would involve Honda and Toyota subclassing a generic Car model. Although they differ in implementation, they can be used in the same way, ensuring that classes and subclasses remain specific and focused on their purpose. This principle is fundamental to object-oriented programming.

Another important concept I learned is how to keep objects and methods concerned only with their own responsibilities. This means that objects and methods should consistently return the expected result, ensuring that whatever relies on them doesn’t need to compensate for inconsistencies.

The book illustrated this through a #verse method that called a #number method. Depending on the context, #number would return either an integer or a string. The issue arose when #verse needed to capitalize the result of #number. Since #capitalize only works on strings, an error would occur if #number returned an integer. To avoid this, #verse had to convert the returned value to a string before capitalizing it.

This workaround introduced unnecessary complexity because #verse couldn’t rely on #number to return a consistent type. The solution was to ensure that #number always returned a string. By making #number dependable, #verse became simpler and easier to use. This example demonstrates how consistency and dependability in code reduce complexity and improve usability. Although this principle seems basic, its impact on a project can be profound.

I’m certain there are concepts I overlooked or sped through during my first read. Even so, the two principles I’ve highlighted—Liskov Substitution and maintaining consistent object responsibilities—are powerful lessons for me as a beginner. I’m eager to apply these ideas in my work and excited to revisit the book in the future to uncover even more insights.