The Java Specialists' Newsletter
Issue 0852004-03-05 Category: Book Review Java version:

Welcome to the 85th edition of The Java(tm) Specialists' Newsletter. Isn't it amazing how quickly our bodies can deteriorate when we work as programmers? When I was at school, I used to go spearfishing about once a week, and I was under the impression that I was unfit. Ha! I had NO idea what unfit really meant. So, here is a challenge for all of us professional Java programmers: Get off your comfortable chair, and do 50 pushups. Yes, you can use both hands. If your boss walks in while you do that, tell him that The Java(tm) Specialists' Newsletter said you should do this. Back in the days when I thought I was unfit, I used to do that in 20 seconds.

I would be interested to hear how many pushups you could do without taking a break, and what the reaction from your co-workers was :-)

For this week's newsletter, I am again reviewing a book, this time "The Pragmatic Programmer - from journeyman to master" by Andrew Hunt and David Thomas. An interesting point of note: This book is the #13 bestseller via Amazon in South Africa. I think that a large portion of all books in South Africa are bought via Amazon, so that is quite an achievement!

Upcoming Java Specialist Master Courses: - please click here to sign up.

As from May 2010, we are also offering this course on the island of Crete. We only accept 6 students per class in Crete, due to the size of our conference room. Please book early to avoid disappointment!

San Jose CA, Mar 16-19 2010, $3500
Ottawa, Canada, Mar 22-25 2010, $3500
Oslo, Norway, Apr 13-16 2010, Kr 24500
Montreal, Canada, Apr 20-23 2010, $3500
Toronto, Canada, May 17-20 2010, $3500
Chania, Crete, May 25-28, Jun 29-Jul 2 or Aug 24-27 2010, €2500

In-house courses if these dates or locations do not suit you - click here for more information.

Book Review: The Pragmatic Programmer

The Pragmatic Programmer was published 15 days after "eXtreme Programming Explained: Embrace Change" by Kent Beck, by the same publishing house. If they had appeared a long time apart, I would have said that they borrowed heavily from each other. That said, I found The Pragmatic Programmer to be more useful.

Dictionary.com has several definitions of "pragmatic", the most appropriate being:

1. Dealing or concerned with facts or actual occurrences; practical; and
2. guided by practical experience and observation rather than theory

Academics are known to be the opposite of pragmatic. It is not always good to be pragmatic, since it can limit your dreaming. There are few "pragmatic" doctorates of computer science research theses. We have to be balanced in our approach. I know of one educational institution in Cape Town that produces programmers who think that any algorithm can be solved by Delphi. When I asked them: Can your marvelous language solve the halting problem algorithm? Can it solve NP-Complete algorithms in polynomial time? The answer was: "Of course". That would be an example of too much pragmatism and not enough theory.

Personally, I prefer a balanced approach. Go to university and learn as much theory as you possibly can. Do at least a Masters of Computer Science. Then keep the theory in the back of your mind, and concentrate on the pragmatic issues surrounding real-life software development. This is where a book like The Pragmatic Programmer will be of tremendous benefit.

The book has lots of tips sprinkled throughout the book. For example:

The book obviously expounds on these tips with lots of examples from real experiences.

Law of Demeter for functions

This law was taken from a paper published in 1989 on "Assuring good style for object-oriented programs". It was nicely described in the book using a C++ class, here it is using Java:

public class Demeter {         // The Law of Demeter for functions
  private A a;                 // states that any method of an
  private int func() { ... }   // object should call only methods
  public void example (B b) {  // belonging to:
    int f = func(); // <--------- itself

    b.invert(); // <------------- any parameters that were passed
                               // in to the method

    a = new A();
    a.setActive(); // <---------- any objects it created
  }
}

After each section there are Exercises with model solutions. Let's have a look at the exercises for the Law of Demeter. Are these method calls allowed according to the Law of Demeter?

public void showBalance(BankAccount acct) {
  Money amt = acct.getBalance();
  printToScreen(amt.printFormat());
}

and

public class Colada {
  private Blender myBlender;
  private Vector myStuff;
  public Colada() {
    myBlender = new Blender();
    myStuff = new Vector();
  }
  private void doSomething() {
    myBlender.addIngredients(myStuff.elements());
  }
}

I would implore you to spend some time thinking about this and applying the rules in the Demeter class before looking at the answer.

Here is the answer from the book for the first question: The method showBalance() breaks the law of demeter. The variable acct is passed in as a parameter, so the getBalance() call is allowed. Calling amt.printFormat(), however, is not. We don't "own" amt and it wasn't passed to us. We could eliminate showBalance's coupling to Money with something like this:

public void showBalance(BankAccount acct) {
  acct.printBalance();
}
  

I must admit that I failed this one miserably. According to the book, research has shown that classes designed in this way will also tend to have fewer errors.

In the second question, since Colada creates and owns both myBlender and myStuff, the calls to addIngredients and elements are allowed.

I have started considering the Law of Demeter when coding my methods. Sometimes I adhere to it, other times not. It is not always easy to change your bad habits, as people who bite their fingernails will tell you.

Automation

Another point that the book emphasises is automation. With the marvelous Ant tool, we really do not have an excuse anymore. Our build process should be completely automated as well as most of our testing. The more you automate, the better chance of you producing systems that are regularly built and tested. Through regression testing, you will pick up problems much quicker.

The book does not mention Ant, since that was developed after the book was published. We have the advantage of being able to set up our build script to run with Ant every night, and then email us the test results. There is a nice product called Anthill that will help you automate the Ant builds and create a project website for your product.

Assertions

Tip 33: If it can't happen, use assertions to ensure that it won't.

The book suggests writing lots of assertion code, and leaving it in the final build that goes to customers. This is the only place I have seen this statement. I have always thought something like this:

Assertions add some overhead to code. Because they check for things that should never happen, they'll get triggered only by a bug in the code. Once the code has been tested and shipped, they are no longer needed, and should be turned off to make the code run faster. Assertions are a debugging facility.

The book says that turning assertions off when you deliver your program to production is like crossing a high wire without a net because you once made it across in practice. They also suggest that many things that your assertions test for simply do not happen during testing, but can happen, even they they cannot, during production.

What concerns me is what happens to an uncaught AssertionError in Java. Ideally you should have a framework that catches all unhandled exceptions and all errors, and issues warnings to the system administrator. Since AssertionError falls under Error and not Exception, we have to be vigilant in handling all Throwables, not just Exceptions.

On a related note, we have Tip 32: Crash early. As soon as you know that there is a problem, crash. Don't try to continue operating with a half-working system. Rather crash. There are different ways that you can crash (not trash). For example, you could send an email to the administrator, or put an entry in a log file. You could end the program completely. However, you have to let someone know that there is a problem. This reminds me of a program that I saw written using J2EE. This program had its own log file, and every time an error occurred, it would write to its log file. No one knew where this log file was located. There were other issues, such as that the log file could grow indefinitely. This could potentially have filled up the hard disk, thus causing more errors. The only way that you could see something was wrong was that the data was not filled in on the screen. No error message on the console, nothing, just deadly quiet (except for the hidden log file). Rather crash early than hide problems.

I can heartily recommend this book as being the best practical advice book on how to write real computer programs in today's environment. I have learnt a lot from "The Pragmatic Programmer" and you will too. Another good book on a similar topic is Code Complete by Steve McConnell.

And now, for some other books...

If I were to dedicate one whole newsletter to each good book that I own, I would be busy for a long time. I have additional books that I want to review, but don't have the time, so this section will list several books, with a short comment

My Brain is Open on the Mathematical Journeys of Paul Erdõs by Bruce Schechter. A fascinating short book about one of the greatest mathematicians of the last century.

Head First Java is a nice book for people who want to learn Java, i.e. not for your typical The Java(tm) Specialists' Newsletter subscriber ;-) It has lots of pictures and diagrams and looks like a schoolbook for 12 year olds (in a positive way!). Despite its comical appearance, I have found that the topics are explained accurately. Full of information, I would recommend this book as a first book for anyone wanting to learn Java from scratch.

Java Enterprise Best Practices contains lots of tips and tricks for topics on EJB, JDBC, RMI, XML, Servlets, JavaMail, etc. It is definitely written for us Java Specialists, rather than beginners. I have applied a few of the ideas and they work well.

Patterns of Enterprise Application Architecture by Martin Fowler. Martin is the best technical writer I know. He writes with a style that is entertaining, yet not irritating (difficult balance). This is an excellent book focusing on enterprise systems. Another great book by Martin Fowler is of course Refactoring, which should be required reading for all Object-Oriented developers.

Java Extreme Programming Cookbook by Eric Burke and Brian Coyner will help you set up an automated system that will make it possible to apply the principles in The Pragmatic Programmer.

That's all for this week :-) Happy reading, and don't forget to do those pushups...

Kind regards

Heinz

Book Review Articles Related Java Course