Introduction

Java is an object-oriented (OO) language in the tradition of Simula-67, SmallTalk, and C++. It borrows syntax from C++ and ideas from SmallTalk. The Java API has been designed and built on the OO model. Design Patterns (see the book of the same name), such as Factory and Delegate, are used throughout; an understanding of these patterns will help you better understand the use of the API and improve the design of your own classes.

Advice, or Mantras

There are any number of short bits of advice that I could give. A few recurring themes arise when learning the basics of Java, and then when learning more Java.

Use the API

I can't say this often enough. A lot of the things you need to do have already been done by the good folks at JavaSoft. And this grows with most releases: 1.2 added the Collections API, and 1.4 added the Regular Expressions API discussed in Chapter 4. Learning the API well is a good grounds for avoiding that deadly "reinventing the flat tire" syndrome coming up with a second-rate equivalent of a first-rate product that was available to you the whole time. In fact, part of this book's mission is to prevent you from reinventing what's already there. One example of this is the Collections API in java.util, discussed in Chapter 7. The Collections API has a high degree of generality and regularity, so there is usually very little reason to invent your own data structuring code.

Generalize

There is a trade-off between generality (and the resulting reusability), which is emphasized here, and the convenience of application specificity. If you're writing one small part of a very large application designed according to OO design techniques, you'll have in mind a specific set of use cases. On the other hand, if you're writing "toolkit-style" code, you should write classes with few assumptions about how they'll be used. Making code easy to use from a variety of programs is the route to writing reusable code.

Read and write Javadoc

You've no doubt looked at the Java online documentation in a browser, in part because I just told you to learn the API well. Do you think Sun hired millions of tech writers to produce all that documentation? No. That documentation exists because the developers of the API took the time to write Javadoc comments, those funny /** comments you've seen in code. So, one more bit of advice: use Javadoc. We finally have a good, standard mechanism for API documentation. And use it as you write the code don't think you'll come back and write it in later. That kind of tomorrow never comes.

See Recipe 23.2 for details on using Javadoc.

Use subclassing and delegation

I can't say this one enough either. Use subclassing. Use subclassing. Use subclassing. It is the best basis not only for avoiding code duplication, but for developing software that works. See any number of good books on the topic of object-oriented design and programming for more details.

An alternative to subclassing is the Design Pattern (see below) known as delegation. For example, instead of subclassing NameAndAddress to make Supplier and Customer, make Supplier and Customer have instances of NameAndAddress. That is a clearer structure and also makes it easier for a Customer to have both a billing address and a shipping address.

Use design patterns

In the Preface, I listed Design Patterns (Addison Wesley) as one of the Very Important Books on object-oriented programming. It provides a powerful catalog of things that programmers often reinvent. It is as important for giving a standard vocabulary of design as it is for its clear explanations of how the basic patterns work and how they can be implemented.

Here are some examples from the standard API:

Pattern name	Meaning	Examples in Java API
Factory Method	One class makes up instances for you, controlled by subclasses	getInstance (in Calendar, Format, Locale...); socket constructor; RMI InitialContext
Iterator	Loop over all elements in a collection, visiting each exactly once	Iterator; older Enumeration; java.sql.ResultSet
Singleton	Only one instance may exist	java.lang.Runtime, java.awt.Toolkit
Memento	Capture and externalize an object's state for later reconstruction	Object serialization
Command	Encapsulate requests, allowing queues of requests, undoable operations, etc.	javax.swing.Action; javax.swing.undo.UndoableEdit
Model-View-Controller	Model represents data; View is what the user sees; Controller responds to user request	Observer/Observable; used internally by all visible Swing components