Customer Reviews

Essential Java Style: Patterns for Implementation

5 star:		(8)
4 star:		(4)
3 star:		(4)
2 star:		(2)
1 star:		(2)

 

 

This book was written by an ex-SmallTalk programmer and works best as an opinionated perspective on Java from the SmallTalk programmer's point of view. Langr does a fair amount of complaining about things he believes are not as well done in Java as in Smalltalk, and while I don't always agree, it's an interesting discussion.

However, one gets the impression that he took a list of patterns that work well in SmallTalk and reimplemented them in Java, rather than coming up with a list of best practices specifically for Java. Some patterns are so awkward in Java that Langr admits to it and doesn't recommend them -- so why mention them at all?

Far too much space is devoted to collections. Most of the recommendations about collections are not really patterns at all, but rather a recapitulation of the API - do we really need a recommendation to use the Stack class to implement a stack? Much tedium could have been avoided simply by recommending that Java developers review the Java collection classes occasionally to avoid inadvertently reinventing the wheel.

In contrast, there's no discussion of multithreading. Java's assumption of threads everywhere is where it differs most from other languages. Many design patterns are changed in the presence of multithreading - the pattern of method calls determines how much work is done atomically and how objects get locked, so refactoring methods is not simply a matter of style.

So, while the book is interesting and brings SmallTalk ideas to a larger audience, it doesn't really work as a definitive style guide for Java.

I come from a similar background as Jeff; COBOL and Smalltalk and I'm just learning Java. The difference between structured/procedural code like COBOL, and true OO code like Smalltalk and Java is significant. I've seen many programmers (including myself) jump to an OO language but still code procedurally. It's a matter of thinking conceptually in objects, and that turns out to be surprisingly difficult for people who have coded procedurally for some time. (This includes Visual Basic, which is not a true OO language). They will think it's OO code, but in reality it isn't, or at least not good OO code.

Jeff's book hightlights the essence of Java from the one-foot level: the actual code. Keeping methods short and sweet is a concept lost on many programmers making the jump to OO. Thinking in terms of patterns of objects interacting with each other is also a change in approach to the way many programmers "intuit" the design of their code.

Learning Java is not as much about learning the syntax as it is about developing object models before you begin coding, and then once you have the model, it's about implementing the methods correctly. I believe Jeff does a nice job of showing us what well formed OO methods really should look and feel like, as well as creating a style framework on which to base an approach to create consistent, reusable code.

Most programming books on the market today cover a particular language, programming technique, or field of computer science. Aside from university texts, which deal with theory, most popular titles deal with practical issues - the nitty-gritty details of day to day software development. They're quick, fast paced, and teach a particular topic, such as Java networking, or JDBC, or Swing/AWT programming. They focus on how to achieve a task, on short-term goals for programmers on the run.

A rarer, but no less important, type of book is one that focuses improving the quality of software development. These type of books usually become industry classics, if written well, and are adopted by universities teaching software engineering classes. But they aren't always relevant to "real-life" software developers, who are often constrained by deadlines and just don't have the time to produce perfectly polished code. The rarest type of book of all is one that combines solid theory, with practical applications. That's the type of book that "Essential Java Style : Patterns for Implementation" attempts to be.

The principle underlying this book is that there are certain ways of writing code that can improve the quality of software, and make it easier to create, modify and debug. The book introduces the reader to the principle of design patterns. Design patterns are reusable templates for software design, that represent tried and true solutions to common problems. Design pattern books have been available for C++ and Smalltalk developers for years - but there has been a shortage of good pattern books for Java. "Essential Java Style" provides real-life code examples in Java, as well as a good discussion of the reasons behind these patterns and how they can aid the software development process.

The patterns are, for the most part, extremely useful and relevant to practical Java programming - though a certain amount of theoretical patterns that will cause an understanding amount of frustration in practical development are also included. My feeling is that some patterns would have been best left out, while others are such a revolutionary idea that every Java programmer should observe them. The challenge, for the reader, is to choose which patterns to adopt, and which to refrain from applying in practice.

While "Essential Java Style : Patterns for Implementation" is an extremely good book for software developers, beginners to design patterns and Java will find the book challenging. In addition, the book suffers from very poor organization -- patterns are not in order, and the reader will have to jump from one to another to gain a thorough understanding. This not withstanding, almost every developer will gain from applying these design patterns to their applications -- not only in the short term, but in the years to come as the application is refined and maintained. The techniques described within "Essential Java Style" : Patterns for Implementation" will most benefit the professional software developer, who is involved in a team project and a medium-to-large-scale software project. -- David Reilly

As soon as your star, ego-swollen developer signs on, you should hand them anything by Booch and also this book. Then quiz him or her. Get your developers on track from day one and prevent the spaghetti code and maintenance nightmare you'll be nursing in two years.

This is an unusually complete pattern guidebook which contains very specific, practical coding gems applicable in any language conducive to object-oriented development e.g. Java, C++, Powerbuilder, and yes, with enough sweat, even VB. It is not a "Patterns for Idiots" book, and it's not the definitive JDK reference, but it sits right in front of me on my desk (with several earmarks).

As a consultant, I'm constantly mulling through others' bad code, and in the back of my mind I'm always thinking "Who was the idiot who taught these folks to code! " The examples in this book will point developers in the right direction, regardless of their background.

The format is excellent, and what I like best about this book is that the author clearly explains when to use a particular pattern and WHY. For example, "What's the difference between a HashTable and HashMap?" Simple question... but when and how to use each one is clearly explained for both JDK 1.1 and 1.2

It is also an excellent "bridge" book for bringing developers from another language into Java, and it lays an excellent foundation for developers of any experience level.

Kudos to Mr. Langr... now please hurry with an "Essential XML Style" book.

This book is composed of short 2-3 page descriptions of some Highly Recommended Programming Practices for the Java language. Some -- like appropriate commenting styles -- will probably be obvious to all but beginning programmers. Others -- like using closures for applying a function to all the elements in a collection -- may be heretofore unimagined concepts (at least for programmers never using other OO languages that have such concepts).

This book is extremely well written. Each concept is framed around the problem that the particular pattern addresses. The concept/pattern is then identified by category and related categories are listed. The mosaic of these mini-patterns provides an extremely gentle introduction to the world of patterns. This would be an appropriate text to read before tackling the seminal GoF book: Design Patterns.

A luxurious amount of the book is dedicated to Collections. And the author carefully shows what operations are available in a limited fashion in the 1.1 JDK and in the enhanced APIs in the 1.2 JDK.

I haven't read the whole book yet. I look forward to reading it over the next few weeks. My only complaint is a less-than-thorough index. However, it is still well-deserving of a five-star rating!

I'm a Smalltalker moving to the world of Java (reluctantly). Having read Kent Beck's excellent book, "Smalltalk Best Practice Patterns", I wanted to read a Java book which covers similar ground.

Langr's book gives ideas on many ways to make your Java code better. If you're like me, you'll find yourself saying, "why didn't I think of that?"

The section on collections is very nice (and Smalltalk-like).

The book is well organized and contains just enough humor to keep the subject matter from being dry. I especially liked the appendix with the pattern summary (I only wish it had a cross reference back to the pages in the book which cover each pattern).

Langr obviously knows his stuff and is good at getting the information across in an understandable fashion.

The "patterns" in the title of this book refers to a collection of coding principles for translating object-oriented designs into Java programs. This is not a design patterns book, but rather a book on Java style, usage, idioms, and best practices.

Because the author comes from a Smalltalk background, the patterns are highly object-oriented. This may be disorienting to developers from a C++ or procedural background, but the longer I program in Java the more I'm convinced that purer OO code is better code. Developers who use UML or object modeling in the design phase will get the most mileage out of this book.

One of the main uses of the book is for use during code reviews. The patterns are named so that you can say "this code should use the Default Value Constant pattern" rather than "I think rule #87 should be applied here". Some of the patterns will be obvious to experienced Java programmers, but are included because many teams have junior programmers who are new to Java. Unfortunately, the book is not organized so that you can quickly find the discussion of a particular pattern. The Pattern Summary does not include page numbers and the Index includes all page numbers where each pattern is mentioned, without bolding or italicizing the pages where the pattern is described.

There are a number of idioms specific to Java that are not covered well in the book. The section on equals does not cover the important case of implementing equals in subclasses and doesn't mention that hashCode should be consistant with equals. There is no coverage of using clone to make copies of objects. In addition, there is a significant amount of outdated and incorrect information. I would recommend using this book in conjuction with another book on Java idioms, such as Effective Java or Practical Java.

Much of the book is distracting because the author continually points out the "deficiencies" of Java. I do agree with many of his comments, but they serve no purpose in this book and quickly become irritating. The frequent comparisons to Smalltalk and C++ are also of little use. I did find that the brace and variable naming conventions did not adhere to Sun's coding conventions, but other than that the book uses standard Java programming style.

Overall, the book is a good one, but I look forward to a new edition that is expanded, corrected, updated, and doesn't have so many useless comments.

Translation into java of kent beck's smalltalk best practice patterns text. Very useful for training new OO programmer at code reviews, can point them at paticular pattern and say fix it that way. Note that this is a book of _coding_ patterns; if you want architecture, see GoF or Grant. Some overlap with Fowler's refactoring book. Am considering making it required reading for all on my projects.........AP

After OO analysis and UML artifacts lies a programmer with a computer and an hopefuly an IDE faced with making decisions on how to implement a design.

That person needs this book.

Beginners and experienced developers alike will benefit from this book because it uses concise examples to explain coding techniques for easier maintenance of source code and better performance. Occasionally, the author describes and example of "BAD" code to illustrate how not to solve a problem and then describes "GOOD" code. Using compare and contrast in this manner helped make the patterns more meaningful and easier to remember.

I wrote Essential Java Style six years ago. At that time, Java was still a new language, yet lots and lots of poorly written code already existed.

Today, there is significantly more poorly written code, and unfortunately, only proportionately more well-written code. It seems like we haven't learned how to write maintainable systems in Java.

I wouldn't change much of the core message in EJS were I to do a rewrite of it. But I would emphasize the three central "patterns" even more: Composed Method, Naming, and the Comment antipattern. Using only these three guidelines as a basis will immediately improve the maintainability of your system.

A rewrite would certainly include more detail based on my experiences in Java. More dramatically, however, the core message would be tempered with the admonition to always write tests for your code. Through test-driven development (TDD) I've found that it's very easy to get into a good habit of keeping your code clean.

To answer some of the review comments:
- the book states the obvious only to those who know what good code is already. Unfortunately this is less than one in five developers.
- I admit that it was intentionally subtitled with the word "patterns" to attract more attention. The material presented within *is* in pattern form.
- a few readers complained about non-standard style. There were only two things that were supposedly non-standard: brace placement, and the use of underscores for fields. Honestly, there is no absolute standard for either of these.
- the book takes a lot of ideas that work well in Smalltalk and applies them to Java. For the most part, this is a valid approach. I'll admit thought that the Smalltalk-like collections approach, unfortunately, isn't a great fit in Java; I no longer bother with them.
- I counted the number of references that denigrate the Java language (mostly for being slow). There were 6. Chalk it up to a sense of humor and frustration at an immature language.

Thanks if you purchased the book! I still see people's references to their dog-eared copy and their happiness with the extent to which they've taken the ideas to heart.