Channels ▼

Got Code Rot? Get It Right with OO

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.”

  • Related Reading

    More Insights

    Currently we allow the following HTML tags in comments:

    Single tags

    These tags can be used alone and don't need an ending tag.

    <br> Defines a single line break

    <hr> Defines a horizontal line

    Matching tags

    These require an ending tag - e.g. <i>italic text</i>

    <a> Defines an anchor

    <b> Defines bold text

    <big> Defines big text

    <blockquote> Defines a long quotation

    <caption> Defines a table caption

    <cite> Defines a citation

    <code> Defines computer code text

    <em> Defines emphasized text

    <fieldset> Defines a border around elements in a form

    <h1> This is heading 1

    <h2> This is heading 2

    <h3> This is heading 3

    <h4> This is heading 4

    <h5> This is heading 5

    <h6> This is heading 6

    <i> Defines italic text

    <p> Defines a paragraph

    <pre> Defines preformatted text

    <q> Defines a short quotation

    <samp> Defines sample computer code text

    <small> Defines small text

    <span> Defines a section in a document

    <s> Defines strikethrough text

    <strike> Defines strikethrough text

    <strong> Defines strong text

    <sub> Defines subscripted text

    <sup> Defines superscripted text

    <u> Defines underlined text

    Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

    Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.