Andy Hunt and Dave Thomas The Pragmatic Programmers have published a brilliant article with the above title in Andy Hunt and Dave Thomas, “OO in one sentence: Keep it DRY, Shy and Tell the Other guy”, IEEE Software, Vol.21 No. 3, pp 101–103, May/June 2004. In outline their main points are:
-
DRY (don’t repeat yourself) states:> Every piece of knowledge must have a single, unambiguous, and authoritative representation representation within a system. (Hunt and Thomas, The Pragmatic Programmer, Addison Wesley, 2000.)
Non-authoritative information (e.g. for EJB all the various interfaces and configuration files) should ideally be generated from the authoritative sources. The DRY principle also applies to build process, code reviews, and documentation.
-
Shy means code should not reveal information about itself unless really necessary. There are four axes of undesirable coupling that violate the Shy principle:
-
static coupling occurs when a program module needs another to compile. Some coupling is often necessary, but it should be minimised. Inheritence is a particularly nasty source of unanticipated coupling and delegation (uses a, has a) is often preferable to is a.
-
dynamic coupling occurs when a class needs the services of another class. A good example of what can go wrong is code like auction.getLot().getHighestBid().getBidder().getPerson() (called a train wreck that appears in one of my lab exercises. The client (auction) needs to know too much about its collaborating classes and is therefore fragile.
-
Domain coupling occurs when too much information about business logic appears in code. It can often be reduced by the judicious use of meta data that is kept in properties or databases.
-
Temporal coupling occurs when code execution is dependent on a particular execution order. Code that may one day be expected to run concurrently should be designed to be concurent.
A corollary of shy code is that code should not be nosy (could be paraphrased as mind your own business!
- Tell the Other Guy [or Tell, Don’t Ask (IEEE Software, Jan/Feb 2003)]. Don’t think of methods as function calls rather as sending a message. Make the other class responsible for providing a service, don’t expect a data return!
Great stuff as usual and well worth quoting in all my software engineering courses!
<
p>While on this note it’s probably worth noting that the Pragmatic Programmers are also bloggers: Andy Hunt blogs in /ndy’s Weblog and Dave Thomas as PragDave. Both are on my Blog role at Bloglines.com.
