Good Books, Smalltalk, and Squeakby Daniel H. Steinberg
Much is made of the fact that Java syntax is similar to C/C++ syntax. The use of the familiar C-like syntax helped Java quickly become a widely accepted language. Experienced programmers new to Java could quickly write working code, but often this code didn't capture the spirit of Java. What was missing was the object-orientedness of Java. You'll find much of Java's OO roots in Smalltalk. Some of the current hot topics in Java aren't news at all to the Smalltalk community.
Like most of you, I'm constantly reading. To keep up with Java, I need to set aside time just to figure out what the latest APIs contain and what new tools are being developed by the open source community. Other reading is intended to "sharpen the Ginsu" so I don't keep trying to cut paper-thin tomato slices after cutting through too many shoes.
In this column, I'll recommend three books I've recently read, along with resources I've found useful along the way. Although two of the books are ostensibly about Smalltalk, reading them has improved my Java programming. As always in this column, I've got fun toys to share with you. This time, I'll point you at a Carbon Smalltalk download called Squeak that works great under Mac OS X. The Cocoa version is coming, but it's still missing some features.
Coming up in the next couple of weeks, I promise a code-packed Java-centric column. There are pending reader requests to look at the speech and spelling APIs. Other columns on the way include Java WebStart and more on XML. One of the books I'll mention in this column is Kent Beck's Guide to Better Smalltalk in the SIGS reference library from Cambridge University Press. I recommend this collection of articles about Smalltalk to Java developers. Without meaning to, Beck also included advice to column writers, advice that I have recently neglected to follow.
Last month, I promised a second installment in the XML series; I've clearly become sidetracked. I'll try to follow Beck's advice and not promise that "next time we'll look at" something unless that next article has been submitted. As always, if you have comments about this column or suggestions for future columns, feel free to email me at DSteinberg@core.com with "O'Reilly Mac Java" as the subject.
Learning OO languages without learning about objects
Every Java program begins its life by invoking a method with the following signature:
public static void main(String args) . Every introductory Java course has to decide how much of that signature is going to be explained to students.
Some instructors start by discussing public vs. private vs. protectected. These instructors go on to explain what a static method is. This particular method doesn't return anything and, therefore, has the return type Void. So even when you have a method with no return value, you have to explain what a return type is.
Then there is the argument that is actually an array of elements of type String. The instructor then explains arrays, primitive types, command line arguments, and possibly, how you would convert the command line argument "127" from the String whose value is 127 to the int whose value is 127. You can be well into the course before students begin to understand that Java is about objects sending messages to each other.
It's true that Java is an object-oriented language. On the other hand, quite a bit of Java programs are very procedural. Back to the first hand: The Java programming language provides the support and infrastructure for writing beautiful object-oriented programs. And yet, a friend teaching a Software Engineering course told me recently of a rather complicated application some of his students were developing that, until the seventh week of the semester, consisted of a single class. Now there are two classes, but most of the functionality remains in a multipage "main()" method in the first class.
This is not a problem that is specific to Java. Many people moved from C to C++ to take advantage of the IO streams in C++. Although they would classify themselves as C++ (and not C) programmers, many would not create or use objects. A friend at another college interviews students who have passed the advanced placement exam in C++ and want to place out of the introductory Java course. He is struck by how many of them have never heard of, or don't easily understand, polymorphism.
Despite the difficulties of the "teach all about main() first" approach, even a more object-centric approach won't mean that students grok objects the first time around. In a graduate text on algebraic topology, Walter Massey describes learning as a process of successive approximations. In OO, this means that you come to an initial understanding of how you should identify objects and let them interact. From this first approximation, you now understand enough to make a leap to a better understanding.
Some people's first approximation is better than others. I came to Java from C. I thought OO was all about inheritance and had these long, fragile chains of subclasses in my early attempts. I now judge an introductory Java text by how early (and how well) polymorphism is introduced. My second approximation to the truth came after reading Bruce Eckel's Thinking in Java and Bill Venners' fine articles on design that he still has posted on http://www.artima.com. Bruce introduced me to the power of polymorphism, and Bill's article on inheritance vs. composition was the first of many articles of his that I read and benefited from.
Daniel has touched on a number of subjects here. What do you have to add?
That brings me to my first recommendation from my current bookshelf: Joshua Bloch's Effective Java Programming Language Guide from the Java Series published by Addison Wesley. If your reading habits are like mine, it is nice to have a book split up into articles that can be read in a five- to ten-minute, ummmm, sitting. Effective Java consists of 57 guidelines split into nine categories, each providing concrete advice about programming in Java. This is a book to get you from your current approximation of how best to program in Java to your next approximation. It is written by a guy who isn't afraid to point out the mistakes he has made in learning these lessons. There are inconsistencies in Sun's APIs that drive us all nuts; this book will help you avoid making those same mistakes.
But wait a minute. What if you aren't writing APIs that you intend to publish? Bloch advises that you program as if your code will be reused. This is a concept that new programmers, particularly those learning to program in an academic setting, don't understand, and it makes learning Java a bit harder. When you design a Java class, think about how other people may use this class. "Other people" may just mean you, but think of yourself as a client for the class. What should an outsider be able to see? What services should the class present to the outside.
One of the nicest features of Effective Java is that Bloch shows the results of ignoring the rule he's discussing. In his discussion of inheritance vs. composition, he shows why inheritance makes the structure more fragile. Here he means inheritance of implementation, and not of interface.
Bloch also points out where inheritance is appropriately used. He ends the section with a wrapper class that provides inheritance of implementation through composition. The first collection of items concerns creating and destroying objects. There's standard advice such as, "avoid finalizers and avoid memory leaks by eliminating obsolete object references."
Other rules may surprise you. Two of the items include suggestions of creating classes with private constructors. The first item in the entire book suggests that a useful alternative to a constructor is a static factory method. In this item, Bloch sets the tone for the book. He provides advantages and disadvantages of using this technique and includes a code sample. The next time you're in a bookstore, pick up this book and read the first item or scan the table of contents for your favorite item. Five minutes later, you'll know if the book is right for you or not. The advice is concrete, well presented in bite size chunks, and full of examples of good and bad design.
Pages: 1, 2