Lot of traffic on the blogosphere about the new Milestone 9 release of Eclipse. Here’s a memo to self to check this out later.
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.
My colleague Tim Davies and I assessed the web sites that form a key part of the UWS Micromouse project that is part of EG-252 Group Design Project. Some really good sites but my favourites were Group B which scored highest for style and Group E which scored highest for content and UML designs. Some bad apples too: Group D doesn’t have a site and Group F doesn’t have much content!
Committed myself to contributing to Headstart and EESW (two summer schools that we run in the School of Engineering) … again! Subject of my bit this year will be Blogging (or more formally Using the Internet as a Research and Collaboration Tool. The idea is that I’ll give the students a potted introduction to the Internet, www, semantic web, rss, blogging etc and then get them to create group blogs focussed on high-performance ballooning (our Summer School topic). The beauty is that Blogger’s new features (including email submission of articles) provide a great way for the students to keep in touch with each other (and UWS of course) when they all disperse to their homes.
Also, as a side issue, I’m hoping that it’ll do a little bit to promote Blogging as a useful school activity.