Dr. Dobb's | Got Code Rot? Get It Right with OO

Got Code Rot? Get It Right with OO

Robert Martin presents an animated guide to better design.

March 27, 2003
URL:http://www.drdobbs.com/got-code-rot-get-it-right-with-oo/184415944

Got Code Rot? Get It Right with OO

Though he’s been giving his talk on advanced principles of object-oriented class design for seven years, Robert Martin keeps it lively and the subject is as vital today as it was a decade ago. Essentially, Martin explained in a Tuesday afternoon tutorial at SD West 2003 in Santa Clara, Calif., OO design is all about dependency management. Then he launched into a story about a trailer welded to the back of a car for greater stability and the problems this caused an unfortunate acquaintance. Soon the audience was paralyzed with laughter as he compared such poor design choices to inheriting a module from a coworker known for his awful code.

“Your boss says, ‘Go get the module from Joe,’ but you know how Joe works.” The audience groaned on cue. “This code has a trailer: It’s got a database, and every line of code is riddled with SQL commands. It’s not reusable because it’s got dependencies on things we didn’t want,” Martin said.

This poor dependency structure is characterized by four negative traits, the author, consultant and popular Software Development columnist explained: It’s rigid, fragile, not reusable and has high viscosity. “Viscosity means two things. On the code level, it’s easier to do the wrong thing than the right one. The other aspect is the development environment: How long does it take to check in a module, to compile, to do other procedures?” So what’s the opposite of highly interdependent code? Code that’s flexible, robust, reusable and fluid.

Suddenly, Martin wheeled on the audience. “How many of you have seen The Wrath of Khan?” he demanded, holding his arm high in the air like an anxious first-grader. “You know, the greatest Star Trek movie? Well, Ricardo Montalban is Khan, and he’s standing before Chekhov and the captain—not Kirk—who are prisoners, and he reaches into a terrarium with these tongs”—Martin pantomimed the entire scene—“and he pulls out this evil creature that’s snapping and writhing”—his arms mimed giant pincers—“and from between the scales he pulls out these slugs. He drops one in Chekhov’s helmet, and another into the captain’s helmet.” Martin paused for effect. “They enter through the ear,” he said, doing his best Khan impersonation, “and they roam through the brain, making you pliable to suggestion. Then, they GROW.” Ominously, Martin asked, “Do any of you have code that’s GROWING?”

What’s That Smell?
The pernicious problem of code rot—programs that get large, stinky and unmanageable over time—is primarily due to bad design choices. The solution? Abstraction: Policy should be independent of details, allowing modifications to occur without crippling side effects or exponentially increasing compile times. It doesn’t matter if the language is object-oriented, so long as implicit classing exists. “If the dependencies all flow toward the interfaces or abstractions, it’s an OO program,” Martin said.

Five principles guide good OO design, according to Martin:

The single responsibility principle (every class should do just one thing);

The open/closed principle (abstracting modules protect them from changes in implementation);

The Liskov substitution principle (a derivative should be indistinguishable from its base class);

The dependency inversion principle (details should depend on abstractions, but not vice versa); and

The interface segregation principle (for help in dealing with “fat” or inappropriate interfaces).

The AI Connection
The strongest relationship in an OO language is inheritance, but how much should you use? In Java, how much should you use extends versus implements? “It’s not a relationship to toss around lightly,” Martin warned. “You have to be very careful of inheritance of implementation, but inheritance of interfaces is very powerful—that’s polymorphism."

One thing that has clouded the field, Martin opined, is the use of various mnemonics such as “is a”, “has a” and “like a” as tests for determining OO relationships. Unfortunately, a square “is a” rectangle, but is not an acceptable derivative class of rectangle because it should not have the same attributes and methods that rectangle has. “There are cases where you’ll use ‘is a’ and fall into this trap,” he explained. “This word phrase thing bothers me because it attempts to trivialize a relationship that’s very technical. We don’t justify for loops with some silly word phrase.” Apparently, the phrases date back to the artificial intelligence boom of the 1980s, which was concurrent with early object-oriented development. “In AI, you had decision trees and knowledge networks. The nodes had dependencies: is a, has a, is like a. A bunch of AI guys stepped across the line and said OO sounded like AI and it stuck—but it doesn’t really fit very well.”