The Shape (and Interface) of Objects to Come

Interfaces evolve and to do so they must first be born. It is more important that a well-defined interface exist than it be perfect. Think about interfaces. Create them intentionally. It is your interfaces, more than all of your tests and any of your code, that define your application and determine its future.

- Sandi Metz, Practical Object-Oriented Design in Ruby, Chapter 4

My adaptation of a sequence diagram

Being a novice to object-oriented programming is a humbling experience. In fact, every time I read POODR, I duly note everything that I have been doing wrong. For instance, I would write very procedural, step-by-step code. I would code before planning. I would consider the nouns of the application, first and foremost, and then build the entire program around these defined classes.

In constructing the tic-tac-toe game, I assumed that I should establish the following classes: the board, AI/computer player, human player (user input), and game. These are called “domain objects” and I often refer to them as part of “the universe” that I am creating. After all, they have data and behavior. They’re obvious manifestations of a virtual reality that is being coded and codified.

Yet, according to Metz, the best way to plan an application is to think about the messages first. Then, consider the necessary objects that pass between them. With domain objects, she forewarns developers of “[coercing] behavior into them” since they exist (this is true). The solution is to, instead, decide on a message and then determine where to send it–and the best tool for that is sequence diagramming.

Sequence diagrams are a way to experiment with different object arrangements and the messages passing between them. They specify the messages that pass between objects and is useful for exposing and experimenting with these interfaces. After learning about this, I decided to go back to the drawing board and re-think my strategy (see above for my first attempt at sequence diagramming).

My five-pointed nuggets of POODR wisdom:

1. Reduce the amount of context that an object needs. This will enable easier testing since there are fewer things needed from their surroundings.
2. Objects need to trust the receiver of a message. Classes only need to know about their own objects; they do not need to know how other classes do things.
3. Use messages to discover any needed objects. This can surface through sequence diagramming and since they are experimental, serve as a starting point for the program’s design.
4. In the public interface, which comprises a class’s exposed methods, focus on the what over the how, have names that will not change, and take a hash as an options parameter. To avoid dealing with unstable code and accruing technical debt, it is advised to engage with public interfaces as much as possible.
5. Follow the Law of Demeter (note: not the Greek goddess of harvest), which helps guide loosely coupled objects by restricting the set of objects to which a method may send messages. It avoids message chaining which relies on public interfaces to target a distant object. If need be, Metz suggests delegating a message by using a wrapper method.

As for me, I am re-evaluating the merits of the tic-tac-toe game that I am currently writing in Ruby. What are the messages? How are they being transmitted? What is being returned? More and more, I am understanding the need for a robust public interface that has enduring methods and deliberately explicit names and logical interactions. Stay tuned for how my Ruby tic-tac-toe game fares!