Not the next big thing! SSS (Small, Simple, Safe) reinvents BlueJ functionality

Daily trawl through the java.blogs feeds picked up a reference to ONJava.com: SSS (Small, Simple, Safe) [May. 26, 2004]. SSS is apparently a simple tool that allows you to instantiate and play with Java objects. It is apparently used and useful in teaching. I simply had to make a comment to the effect that BlueJ has had this feature for ever! Here’s my reponse in full:

BlueJ is a simple Java IDE (avalable from http://www.bluej.org) which also has this sort of behaviour. You can instantiate an object of any class on the classpath by providing the fully qualified name and then selecting any of the class’s constructors. Once the object has been instantiated and a small icon (sort of like a UML object diagram) appears. You can then right-click on the “object” to call any of the object’s methods. Because BlueJ is an IDE and debugger it has privileged access to the JVM, which allows you to also inspect the object to see all its private state.

BlueJ has built up quite a following in the educational arena just lately and there are several “CS101″ text books using it (but none from O’Reilly). See the web site quoted above for more info and access to the lively discussion lists.

It’ll be interesting to see if there is any feedback!

Keep it DRY, keep it shy and tell the other guy

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.

Balloon Blogging

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.

Jam Tomorrow

Something to look into:

“JAM leverages the new import and target override features of Ant 1.6 to create a reusable, consistent Java build framework. JAM modules support JBoss, XDoclet, JUnit, Cactus, Struts, Castor, Resin and MDA/UML code generation. Maven’s POM and repository features are supported via a Maven-to-Ant bridge.”

<

p>Thanks to New Build Tool: J2EE + Ant = JAM on theServerSide.