Jack J. Woehr
Of the many books I've read this year with "Patterns" in the title, Essential Java Style: Patterns for Implementation, by Jeff Langr, is the first that I could fully enjoy.
Harry S Truman once said of youngsters seeking autographs, "It's like dogs p***ing on a hydrant, one of them does it and the rest of them all have to do it." Lately it's been that way with "Patterns" books, many consisting largely of naive attempts to recast all of computer science in the light of the latest pop computer-science trend.
Java Style is different. Langr enthuses for the new metaphor and serves his patterns straight to the true believer. But Langr's work is also illuminated by mature insight into the relation of patterns to the rest of theory, and in particular, to the theory of design implicit in the carefully engineered constraints of the Java development environment.
Java Style is ambitious. While Langr humbly avows that "the patterns...within this book are very specific code-level patterns...not subsystem design patterns," he has, in effect, offered us the prototype of a standard pattern library as it applies to Java programming, a library analogous to the standard C library, or to the standard template library for C++. Although the patternification of programming environments has not in practice progressed quite so far that we should hasten to convene for an ISO standard, Langr's opus is a bit of evidence for the point-of-view that we are approaching that point very rapidly.
It's hardly coincidental that Langr conceptually concatenates issues of patterns with issues of style. Langr's examples and his explanations of how his models evolved bear witness to the author's meticulous coding. Langr's pattern emerges less from intuitive recognition of hidden similarities than from diligence in collating identity sets made to leap from the pages of his lucid, orthogonal, and workman-like source.
I'm not sure that I agree with all, or even with the majority, of the assumptions and prescriptions found in Java Style. Indisputably, however, Java Style is a thought-provoking, professional evangel for the patternification of Java development. Langr is convincing in that he, at least, among the patternists understands factoring. Many peer works suffer from overambition and isotropism. Langr is content to apply his theory methodically and with an admirable thoroughness to the foundations. I look forward with interest to reading in later volumes well-documented case studies of the results of the application of his pattern library.
Java Style as a book benefits from competent editing, excellent page layout, and attractive design. Appropriate font changes enhance readability. Code samples are adequately annotated and formatted. The latter quality redounds to the credit of the designer, who labored with success within the narrow column space on the pages of this handbook-sized printing.
It's hoped, or assumed, that the publisher intends to release a CD-ROM of Java Style, as this book is eminently suited to an online work.
Electronic Review of Computer Books
Standardizes a common Java coding style defined in terms of patterns. The patterns cover methods, messages, state, collections, classes and formatting, and streamline the development process by eliminating random coding and naming styles that complicate maintenance. Annotation c. Book News, Inc., Portland, OR (booknews.com)
Read an Excerpt
Each time I learned a new language, I began to recognize and identify specific things that I was doing over and over in my code. Back in my COBOL days (the early 1980s), these repeated bits of code weren't known by the now-ubiquitous buzzword "patterns," but they were most certainly coding constructs that I was aware of and that I actively reused. Since then I have worked extensively with Pascal, C, C++, Smalltalk, and now Java. The spe-cific constructs may have changed, but the concept of a reusable pattern has remained.
To remember these constructs, I typically would save off snippets of code into small, stand-alone demonstration programs. When I encountered the need for a construct that I had already coded, I searched my directory of code chunks, and hopefully found the one that would work well in my new coding challenge. If I was fortunate, I achieved object nirvana reuse! Organizationally speaking, though, this is a less-than-ideal system, and certainly other developers would have a difficult time finding anything useful in my grab-bag of example programs.
Somewhat sadly, I still use this technique in Java today, with only minor improvements. The better Java IDEs today support the concept of a scratch pad or workspace, something that Smalltalk has had for years. These scratch pads allow you to quickly code and test snippets of code on the fly without requiring you to create a new project, open a new file, type all the supporting code, save the code, and so forth. But in the end it's still a random list of solutions that is of little value to other developers.
With this book, then, I offer an improvedsolution. I intend to fill a void that most of the innumerable Java books available do not address. I explain neither how the language works nor how to use the class libraries. Instead, I describe low-level coding patterns that describe how to properly write Java code. If used appropriately, these patterns can be used as the standard for building cost-effective, universally maintainable systems.
Coming to Java from Smalltalk, I am already encountering what I have experienced too often before with C++ and other languages:
- Widely varying coding style;
- Overly procedural code that is difficult to understand;
- Inconsistent, overly terse and misleading method, identifier, and class naming;
- Widely different techniques for common operations, such as instance creation and lazy initialization.
These practices are unfortunate and only drive up the cost of code maintenance. In comparison, the Smalltalk development community has a very established, embedded culture. This culture promotes standards and practices that you adhere to without the enforcement of a compiler. The benefit of adherence to these standards is considerable, as I no longer need to fig-ure out individual programmer styles in order to effectively understand their code.
My hope is to someday see in the Java community the amount of consistency and clarity for which the Smalltalk community strives. This book is my effort to provide such a basis for clear code communication.
If you are a developer and are not aware of the driving force that patterns have become in the industry, you have probably been sleeping in your cubi-cle. There are dozens of books available on the topic. Design Patterns is the father of all software pattern books. Unfortunately, as buzzwords go, too many things today are expressed in terms of patterns, whether or not it makes sense. "Patterns" is to the late 1990s as "client/server" was to the early 1990s.
The best advantage to using patterns, from my experience, is that you now have a clear means of communicating common design concepts. Used properly, patterns allow you to communicate not just within your work-group, your company, or your industry, but within the entire development community.
Other industries have long adopted patterns and appropriate names for them. Without names for their patterns, architects would have to tell you they were designing "a small, open hall immediately inside the front entrance to the house that will act as a waiting area" instead of just using the word "foyer." For Java development and maintenance to be most cost-effective, the development community similarly needs to adopt a common language of coding patterns.
When hiring a plumber to install a new bathtub, you assume he or she knows how to get it to mesh with your house properly, regardless of whether you use copper plumbing, PVC, or a large bucket to fill your tub. Similarly, a new Java maintenance programmer coming on board should be able to maintain the system by first assuming that the common pattern lan-guage has been used. Once this assumption has been proven correct, the programmer should be able to rapidly look at existing code to determine its intent and structure.
The patterns contained within this book are very specific coding-level patterns. They are generally not subsystem design patterns like those contained in Design Patterns. My main intent (and intent is a key word when considering patterns) is to present a guidebook for a common Java coding style defined in terms of patterns.
Other books on style have a significant shortcoming the styles are not named. For rules to be useful, they must somehow be internalized by all developers involved. Without the benefit of descriptive names, it is difficult to understand and communicate specific rules. (What was rule #121 again?) Essential Java Style, and patterns in general, rectify this by providing a precise set of names for the rules.
Regarding intent, the most important thing to do when you are coding is to ensure that someone else will be able to quickly understand what the heck you were thinking. Too often a maintainer has to try to read the mind of a programmer who may be long gone. Clairvoyance is a good skill to have, but unfortunately it is not prevalent in the software development industry. Comments sometimes help, but more often than not the comments are inaccurate, out of date, or don't add value to what the code already states.
If you follow the patterns in this book, the amount of your code that will need commenting should decrease significantly. While the promise of self-documenting code is rarely fulfilled, these patterns give you the best oppor-tunity to allow your code to declare just what it is doing. If you are writing lots of comments to explain things, then your code is not declaring its intent in a simple fashion and could use some cleaning up.
This emphasis on clean, understandable code is extremely important, because maintenance is the costliest part of a typical development shop. The ability to rapidly fix, amend, or enhance code is one of the chief promises of object-oriented development. The reality will only come when coders learn to express themselves clearly and consistently.
Essential Java Style: Implementation Patterns
What are these patterns? Are they about style or standards? Or neither?
Style is an imprecise word. The word style connotes flash, panache, coolness. On the opposite end of the spectrum, the word standards connotes stodginess, inflexibility, tedium. Neither term accurately describes the goal of this book, which is why it has a subtitle: Patterns for Implementation. I also think that people only reluctantly buy books on standards, so that was left out of the title completely.
There are few hard-and-fast programming rules. Most of these patterns reflect just one possible solution to recurring implementation questions. So the patterns cannot be absolute standards. Yet the patterns do decide what should be the usual and expected solution to a problem. The preferred solution identified by each pattern is generally the simplest, not the most creative. So this book is not about style in the classic sense either.
What these patterns do is provide guidelines for development and a common language with which to communicate these guidelines. All of the patterns have specific names to assist you in internalizing them. The collection of pattern names is the vocabulary for the pattern language.
This book uses a pattern itself for the naming of its patterns. The bulk of the patterns described are the same as those contained within Smalltalk Best Practice Patterns by Kent Beck. Obviously, there are some key differences between the two languages, but other than syntax, Smalltalk has more in common with Java than either C or C++. Many of the extremely useful concepts presented in Beck's book translate very closely to Java. With generous thanks to Beck, I have reused his set of patterns where applicable.
Who This Book Is for
If you program, read, test, or document Java code, Essential Java Style is for you. It is not intended as a programming primer or a class reference, but some of the patterns contained in it will explain Java concepts where necessary. I assume the reader has some minimal knowledge of Java programming, but the reader does not need to be a Java expert to use this book effectively.
Essential Java Style is especially geared toward team development. The patterns provide a common language for communication of implementation concepts. But even if you are the only one who ever looks at your own code, the patterns within will still help you improve your development efforts.
On a personal basis, I have been exposed to Java for three years, working in depth with the language over the past year. I do not consider myself a Java expert, but I do have considerable experience in various other languages. Clean coding is something I have striven for throughout my career. Code almost never exists in a vacuum someone will be reading or maintaining your code in the future. Unlike a muddled movie, which can be walked out on, some poor soul may have to understand your code, like it or not. If you respect your fellow developer, you will strive for clear code.
What You'll Need
Essential Java Style is intended to be a manual of style. To get started, all you really need is a Java toolkit or IDE and this book. The latest JDK can always be downloaded from ...