Items related to Learning Java
Synopsis
A tutorial introducing Java basics covers programming principles, integrating applets with Web applications, and using threads, arrays, and sockets.
"synopsis" may belong to another edition of this title.
About the Author
(pat@pat.net) became involved with Oak (Java's predecessor) while working at Southwestern Bell Technology Resources. He is an independent consultant and author in the areas of networking and distributed applications. Pat is the author of BeanShell, a popular Java scripting language, as well as various other free goodies on the Net. Most recently, Pat has been developing enterprise architecture for A.G. Edwards. He currently lives in the Central West End area of St. Louis with various creatures.
Jonathan Knudsen is an author at O'Reilly & Associates. His books include The Unofficial Guide to Lego Mindstorms Robots, Java 2D Graphics, and Java Cryptography. He is the Courseware Writer for LearningPatterns.com.
Excerpt. © Reprinted by permission. All rights reserved.
CHAPTER 8 Generics
It’s been almost 10 years since the introduction of the Java programming language (and the first edition of this book). In that time, the Java language has matured and come into its own. But only with Java 5.0, the sixth major release of Java, did the core language itself change in a significant way. Yes, there were subtle changes and drop-ins over the years. Inner classes, added very early on, were important. But no language improvements prior to this point have affected all Java code or all Java developers in the way that Java 5.0 will.
Generics are about abstraction. Generics let you create classes and methods that work in the same way on different types of objects. The term "generic" comes from the idea that we’d like to be able to write general algorithms that can be broadly reused for many types of objects rather than having to adapt our code to fit each circumstance. This concept is not new; it is the impetus behind object-oriented programming itself. Java generics do not so much add new capabilities to the language as they make reusable Java code easier to write and easier to read.
Generics take reuse to the next level by making the type of the objects we work with an explicit parameter of the generic code. For this reason, generics are also referred to as parameterized types. In the case of a generic class, the developer specifies a type as a parameter (an argument) whenever she uses the generic type. The class is parameterised by the supplied type, to which the code adapts itself.
In other languages, generics are sometimes referred to as templates, which is more of an implementation term. Templates are like intermediate classes, waiting for their type parameters so that they can be used. Java takes a different path, which has both benefits and drawbacks that we’ll describe in detail in this chapter.
There is much to say about Java generics and some of the fine points may be a bit obscure at first. But don’t get discouraged. The vast majority of what you’ll do with generics is easy and intuitive. The rest will come with a little patience and tinkering.
We begin our discussion with the most compelling case for generics: container classes and collections. Next, we take a step back and look at the good, bad, and ugly of how Java generics work before getting into the details of writing generic classes. We then introduce generic methods, which intelligently infer their parameter types based upon how they are invoked. We conclude by looking at a couple of real-world generic classes in the Java API.
Containers: Building a Better Mousetrap
In an object-oriented programming language like Java, polymorphism means that objects are always to some degree interchangeable. Any child of a type of object canserve in place of its parent type and, ultimately, every object is a child of java.lang. Object, the object-oriented "Eve," so to speak. It is natural, therefore, for the most general types of containers in Java to work with the type Object so that they can hold most anything. By containers, we mean classes that hold instances of other classes in some way. The Java Collections Framework is the best example of containers. A List, for example, holds an ordered collection of elements of type Object. A Map holds an association of key-value pairs, with the keys and values also being of the most general type, Object. With a little help from wrappers for primitive types, this arrangement has served us well. But (not to get too Zen on you), in a sense, a "collection of any type" is also a "collection of no type," and working with Objects pushes a great deal of responsibility onto the user of the container.
It’s kind of like a costume party for objects where everybody is wearing the same mask and disappears into the crowd of the collection. Once objects are dressed as the Object type the compiler can no longer see the real types and loses track of them. It’s up to the user to pierce the anonymity of the objects later using a type cast. And like attempting to yank off a party-goer’s fake beard, you’d better have the cast correct or you’ll get an unwelcome surprise.
Date date = new Date( );
List list = new ArrayList( );
list.add( date );
...
Date firstElement = (Date)list.get(0); // Is the cast correct? Maybe.
The List interface has an add( ) method that accepts any type of Object. Here, we assigned an instance of ArrayList, which is simply an implementation of the List interface, and added a Date object. Is the cast in this example correct? It depends on what happens in the elided "..." period of time.
Can Containers Be Fixed?
It’s natural to ask if there is a way to make this situation better. What if we know that we are only going to put Dates into our list? Can’t we just make our own list that only accepts Date objects, get rid of the cast, and let the compiler help us again? The answer, surprisingly perhaps, is no. At least, not in a very satisfying way.
Our first instinct may be to try to "override" the methods of ArrayList in a subclass. But of course, rewriting the add( ) method in a subclass would not actually override anything; it would add a new overloaded method.
public void add( Object o ) { ... }
public void add( Date d ) { ... } // overloaded method
The resulting object still accepts any kind of object—it just invokes different methods to get there.
"About this title" may belong to another edition of this title.
- PublisherOreilly & Associates Inc
- Publication date2006
- ISBN 10 1600330010
- ISBN 13 9781600330018
- BindingPaperback
- LanguageEnglish
- Edition number3
- Number of pages856
(No Available Copies)
Search Books: Create a WantCan't find the book you're looking for? We'll keep searching for you. If one of our booksellers adds it to AbeBooks, we'll let you know!
Create a Want
