Summary

This chapter attempts to give you a feel for the broad issues of object-oriented programming and Java, including why OOP is different, and why Java in particular is different.

OOP and Java may not be for everyone. It’s important to evaluate your own needs and decide whether Java will optimally satisfy those needs, or if you might be better off with another programming system (including the one you’re currently using). If you know that your needs will be very specialized for the foreseeable future and if you have specific constraints that may not be satisfied by Java, then you owe it to yourself to investigate the alternatives (In particular, I recommend looking at Python; see www.Python.org). Even if you eventually choose Java as your language, you’ll at least understand what the options were and have a clear vision of why you took that direction.

You know what a procedural program looks like: data definitions and function calls. To find the meaning of such a program, you have to work a little, looking through the function calls and low-level concepts to create a model in your mind. This is the reason we need intermediate representations when designing procedural programs—by themselves, these programs tend to be confusing because the terms of expression are oriented more toward the computer than to the problem you’re solving.

Because Java adds many new concepts on top of what you find in a procedural language, your natural assumption may be that the main( ) in a Java program will be far more complicated than for the equivalent C program. Here, you’ll be pleasantly surprised: A well-written Java program is generally far simpler and much easier to understand than the equivalent C program. What you’ll see are the definitions of the objects that represent concepts in your problem space (rather than the issues of the computer representation) and messages sent to those objects to represent the activities in that space. One of the delights of object-oriented programming is that, with a well-designed program, it’s easy to understand the code by reading it. Usually, there’s a lot less code as well, because many of your problems will be solved by reusing existing library code.

^[2] Some language designers have decided that object-oriented programming by itself is not adequate to easily solve all programming problems, and advocate the combination of various approaches into multiparadigm programming languages. See Multiparadigm Programming in Leda by Timothy Budd (Addison-Wesley 1995).

^[3] This is actually a bit restrictive, since objects can conceivably exist in different machines and address spaces, and they can also be stored on disk. In these cases, the identity of the object must be determined by something other than memory address.

^[4] Some people make a distinction, stating that type determines the interface while class is a particular implementation of that interface.

^[5] I’m indebted to my friend Scott Meyers for this term.

^[6] This is usually enough detail for most diagrams, and you don’t need to get specific about whether you’re using aggregation or composition.

^[7] Primitive types, which you’ll learn about later, are a special case.

^[8] Except, unfortunately, for primitives. This is discussed in detail later in the book.

^[9] Microsoft is effectively saying “not so fast” with C# and .NET. Numerous people have raised the question of whether VB programmers want to change to anything else, whether that be Java, C#, or even VB.NET.