"The map appears more real to us than the land."

-Lawrence

Writing Code That Doesn't Suck and Interface-Oriented Design

Published by Thomas Schreiber on Sep 28, 2009 at 3:35 AM.

After watching Yehuda Katz's talk Writing Code That Doesn't Suck I was convinced to read Interface-Oriented Design by Ken Pugh. Combined, the video and the book greatly enhanced my understanding of what it means to write clean, pluggable, and well tested software.

I have been struggling with how to start using Test Driven Development since I first learned of the concept. So when this talk, Writing Code That Doesn't Suck popped up on my radar, I was ready to absorb. Yehuda Katz, a core Rails, Merb, and JQuery developer, explained how during a major Merb refactor, they had to throw away all of their Unit tests, because refactoring broke every test practically. In their newer release of Merb they concentrated on testing the interfaces between components, not just the units.

This style is known as functional testing or behavior testing, and I must emphasize, that by no means is there a suggestion of abandoning unit testing all together. One still must test the code for robustness and performance. The point is that fine-grained inner system tests don't live through a refactor well, and more importantly they often don't test the most essential parts of the application. A thoughtful combination of both unit tests and functional tests is the key.

Like any other title from The Pragmatic Bookshelf, the language in Interface-Oriented Design is clear, concise, and doesn't go deep into code examples. I was able to comprehend some basic design patterns and object oriented idioms that traditional computer science and reference books made overwhelming. This excerpt : The Design Patterns book states, “Design to an interface, not an implementation.” A parallel guideline exists in testing. “Test to an interface, not an implementation”. This is termed black box testing. Even though I'm not entirely knowledgeable with the technologies or programming languages used throughout the book (Java and printer driver development), the code examples were easily followed and kept focus on theories and concepts of substance.

At the beginning of the second chapter, Ken jumps right into the three laws of interface design: 1. An Interface’s Implementation Shall Do What Its Methods Says It Does 2. An Interface Implementation Shall Do No Harm 3. If An Implementation Is Unable to Perform Its Responsibilities, It Shall Notify Its Caller Keeping these laws in mind, the next four chapters are devoted to interface interaction and the trade-offs inherent in the design decisions one makes along the way when building interfaces. This topic is of great interest to me as a Django developer, because of how fundamental reusable apps are to a Django project and API's are to web apps.

The next sections take programming problems and runs them through the agile process, step by step, without getting bogged down by detailed explanations. The steps are vision, conceptualization, analysis, design, tests, implementation, and retrospective. In the spirit of The Pragmatic Programmer, this part of the book contains excellent real-world examples of putting agile to practice; a birds eye view of the process required to arrive at a clean solution for any problem.

The last chapter covers in detail a few design patterns that are specific to interface design. This part certainly motivated me to give Design Patterns by the Gang of Four another chance. Also the appendix is full of useful tidbits that didn't fit into the rest of the book.

In closing, I must say that I really appreciate Ken's insight into the the classic computer science books he has read, that I haven't. I want to and will get around to reading 'Design Patterns', 'The Art of Computer Programming', and others but I only have so much patience and time for heavily academic titles. Interface-Oriented Design when combined with James Bennett's Practical Django Projects allows one to quickly grasp the best practices of software design as it relates to Django. One more title on testing and I'm ready to jump over that hurdle. Although its a ROR title, I might just give The RSpec book a shot along trying out Sebastian Hillig's Banana cucumber in yellow and python.

blog comments powered by Disqus