Sponsored Link •
Martin Fowler, chief scientist at Thoughtworks, Inc. and author of numerous books on software design and process, talks with Bill Venners about design principles and the spectrum of code ownership.
Over the last decade, Martin Fowler pioneered many software development techniques in the development of business information systems. He's well known for his work on object-oriented analysis and design, software patterns, Unified Modeling Language, agile software processes (particularly extreme programming), and refactoring. He is the author of Analysis Patterns (Oct. 1996), Refactoring (June 1999; coauthored with Kent Beck, et al.), UML Distilled (Aug. 1999; with Kendall Scott), Planning Extreme Programming (Oct. 2000; with Kent Beck), and the soon to be released Patterns of Enterprise Application Architecture (Nov. 2002), all published by Addison Wesley.
In this six-part interview, which will be published in weekly installments, Fowler gives his views on many topics, including refactoring, design, testing, and extreme programming. In Part I, Fowler makes the business case for refactoring and testing, and describes the interplay between refactoring, design, and reliability. In this second installment, Fowler discusses design principles of avoiding duplication, separating presentation and domain logic, being explicit, and describes how refactoring depends on code ownership.
Bill Venners: In your book, Refactoring you say, "The code says everything once and only once, which is the essence of good design." Why do you think the essence of good design is once and only once?
Martin Fowler: One of the things I've been trying to do is look for simpler or rules underpinning good or bad design. I think one of the most valuable rules is avoid duplication. "Once and only once" is the Extreme Programming phrase. The authors of The Pragmatic Programmer (October 1999; by Andrew Hunt and David Thomas) use "don't repeat yourself," or the DRY principle.
You can almost do this as an exercise. Look at some program and see if there's some duplication. Then, without really thinking about what it is you're trying to achieve, just pigheadedly try to remove that duplication. Time and time again, I've found that by simply removing duplication I accidentally stumble onto a really nice elegant pattern. It's quite remarkable how often that is the case. I often find that a nice design can come from just being really anal about getting rid of duplicated code.
Bill Venners: You said you've been trying to figure out the basic principles of good design. Besides once and only once or DRY, what other basic principles have you come across?
Martin Fowler: I think another good principle is separating presentation or user interface (UI) from the real essence of what your app is about. By following that principle I have gotten lucky with changes time and time again. So I think that's a good principle to follow.
Bill Venners: When you say lucky with changes, do you mean in the future it's easier to make changes?
Martin Fowler: Later on I have to make some change, and it's just a lot easier because the presentation and domain are separated. Testing also becomes easier when you separate presentation and domain logic. It's a principle that has worked very well for me. I think it makes a good base principle.