Two Great Takeaways from GOOS

I recently just finished reading Growing Object-Oriented Software, Guided by Tests (or GOOS for short) by Nat Pryce and Steve Freeman. I highly recommend every developer pick up a copy and give it a read. It is full of great advice for building a well-tested, high quality application. I wanted to pick out two particular gems I found towards the end of the book that I felt are really powerful.

[W]e like to have names for the relationships between objects as well as objects themselves. As the legends say, if we have something's true name, we can control it.
Growing Object-Oriented Software Guided by Tests, page 244 (authors' emphasis)

They are talking specifically about preferring to mock interfaces rather than concrete implementations, but this concept bubbles up generally throughout the book. They use interfaces extensively, even noting that their use is above average, to tease out concepts and relationships in the code. Many in the community feel that interfaces are just needless over-engineering and over-specifying of an object. Here, though, the authors turn that idea on it's head. Interfaces don't specify objects, they define relationships. By giving a name and a form to a relationship, we can control it, vary it, talk about it, and show it. It is something real in the system, not an implicit concept buried inside of our code.

To design is to communicate clearly by whatever means you can control or master.
– Milton Glaser, Growing Object-Oriented Software Guided by Tests, page 247

Here is a quote the authors chose to emphasize the subject of the chapter, but the quote itself is very prescient. It frames design as a form of communication. We don't design in a vacuum. Our designs should tell the next person that reads it about our software. We can judge the quality of our design by how effectively it communicates our intent and our knowledge. Good design is not just full of patterns or abstractions, but is measured at the ability to convey ideas.

This quote, of course, goes far beyond just software design. We can look at the designed things of the world around us in the context of communicating with us. We can judge their design by how well they tell us what we need to know.


Popular posts from this blog

The Timeline of Errors

Magic Numbers, Semantics, and Compiler Errors

Assuming Debugging