Advertisement: Support JavaWorld, click here!
March 1999HOMEFEATURED TUTORIALSCOLUMNSNEWS & REVIEWSFORUMJW RESOURCESABOUT JW
ARCHIVE
TOPICAL INDEX
Core Java
Enterprise Java
Micro Java
Applied Java
Java Community
JAVA Q&A INDEX
JAVA TIPS INDEX
JavaWorld Services
Free JavaWorld newsletters
ProductFinder
Education Resources
White Paper Library
NEW! Rational Resources
Design Techniques
Design with static members
How to put static fields and methods to work
Summary
In this installment of his Design Techniques column, Bill Venners discusses the ways in which static fields and methods, which exist outside of objects, fit in a design that's object-oriented. (1,500 words)
By Bill Venners
Printer-friendly version | Mail this to a friend
Page 1 of 2
Advertisement
lthough Java is object-oriented to a great extent, it is not a pure object-oriented language. One of the reasons Java is not purely object-oriented is that not everything in it is an object. For example, Java allows you to declare variables of primitive types (int, float, boolean, etc.) that aren't objects. And Java has static fields and methods, which are independent and separate from objects. This article gives advice on how to use static fields and methods in a Java program, while maintaining an object-oriented focus in your designs.
The lifetime of a class in a Java virtual machine (JVM) has many similarities to the lifetime of an object. Just as an object can have state, represented by the values of its instance variables, a class can have state, represented by the values of its class variables. Just as the JVM sets instance variables to default initial values before executing initialization code, the JVM sets class variables to default initial values before executing initialization code. And like objects, classes can be garbage collected if they are no longer referenced by the running application.
Nevertheless, significant differences exist between classes and objects. Perhaps the most important difference is the way in which instance and class methods are invoked: instance methods are (for the most part) dynamically bound, but class methods are statically bound. (In three special cases, instance methods are not dynamically bound: invocation of private instance methods, invocation of init methods (constructors), and invocations with the super keyword. See Resources for more information.)
Another difference between classes and objects is the degree of data hiding granted by the private access levels. If an instance variable is declared private, only instance methods can access it. This enables you to ensure the integrity of the instance data and make objects thread-safe. The rest of the program cannot access those instance variables directly, but must go through the instance methods to manipulate the instance variables. In an effort to make a class behave like a well-designed object, you can make class variables private and define class methods that manipulate them. Nevertheless, you don't get as good a guarantee of thread safety or even data integrity in this way, because a certain kind of code has a special privilege that gives them direct access to private class variables: instance methods, and even initializers of instance variables, can access those private class variables directly.
So the static fields and methods of classes, although similar in many ways to the instance fields and methods of objects, have significant differences that should affect the way you use them in designs.
Treating classes as objects
As you design Java programs, you will likely encounter many situations in which you feel the need for an object that acts in some ways like a class. You may, for example, want an object whose lifetime matches that of a class. Or you may want an object that, like a class, restricts itself to a single instance in a given name space.
In design situations such as these, it can be tempting to create a class and use it like an object in order to define class variables, make them private, and define some public class methods that manipulate the class variables. Like an object, such a class has state. Like a well-designed object, the variables that define the state are private, and the outside world can only affect this state by invoking the class methods.
Unfortunately, some problems exist with this "class-as-object" approach. Because class methods are statically bound, your class-as-object won't enjoy the flexibility benefits of polymorphism and upcasting. (For definitions of polymorphism and dynamic binding, see the Design Techniques article, Composition versus Inheritance.) Polymorphism is made possible, and upcasting useful, by dynamic binding, but class methods aren't dynamically bound. If someone subclasses your class-as-object, they will not be able to override your class methods by declaring class methods of the same name; they will only be able to hide them. When one of these redefined class methods is invoked, the JVM will select the method implementation to execute not by the class of an object at runtime, but by the type of a variable at compile time.
In addition, the thread safety and data integrity achieved by your meticulous implementation of the class methods in your class-as-object is like a house built of straw. Your thread safety and data integrity will be guaranteed so long as everyone uses the class methods to manipulate the state stored in the class variables. But a careless or clueless programmer could, with the addition of one instance method that accesses your private class variables directly, inadvertently huff and puff and blow your thread safety and data integrity away.
For this reason, my main guideline concerning class variables and class methods is:
Don't treat classes like objects.
In other words, don't design with static fields and methods of a class as if they were the instance fields and methods of an object.
If you want some state and behavior whose lifetime matches that of a class, avoid using class variables and class methods to simulate an object. Instead, create an actual object and use a class variable to hold a reference to it and class methods to provide access to the object reference. If you want to ensure that only one instance of some state and behavior exists in a single name space, don't try to design a class that simulates an object. Instead, create a singleton -- an object guaranteed to have only one instance per name space.
Next page >
Page 1 Design with static members
Page 2 So what are class members good for?
Printer-friendly version | Mail this to a friend
Resources
Bill Venners' next book is Flexible Java
http://www.artima.com/flexiblejava/index.html
An complete online reprint of Chapter 7, "The Linking Model," of Bill Venners' book Inside the Java Virtual Machine
http://www.artima.com/insidejvm/linkmod.html
The handout and slides for Bill Venners' Dynamic Extension in Java talk.
http://www.artima.com/javaseminars/modules/DynaExt/index.html
Bill Venners recently returned from his European bike trip. Read about it at:
http://www.artima.com/bv/travel/bike98/index.html
The discussion forum devoted to the material presented in this article
http://www.artima.com/flexiblejava/fjf/classes/index.html
Links to all previous design techniques articles
http://www.artima.com/designtechniques/index.html
Recommended books on Java design
http://www.artima.com/designtechniques/booklist.html
A transcript of an e-mail debate between Bill Venners, Mark Johnson (JavaWorld's JavaBeans columnist), and Mark Balbe on whether or not all objects should be made into beans
http://www.artima.com/flexiblejava/comments/beandebate.html
Object orientation FAQ
http://www.cyberdyne-object-sys.com/oofaq/
7237 Links on Object Orientation
http://www.rhein-neckar.de/~cetus/software.html
The Object-Oriented Page
http://www.well.com/user/ritchie/oo.html
Collection of information on OO approach
http://arkhp1.kek.jp:80/managers/computing/activities/OO_CollectInfor/OO_CollectInfo.html
Design Patterns Home Page
http://hillside.net/patterns/patterns.html
A Comparison of OOA and OOD Methods
http://www.iconcomp.com/papers/comp/comp_1.html
Object-Oriented Analysis and Design Methods: A Comparative Review
http://wwwis.cs.utwente.nl:8080/dmrg/OODOC/oodoc/oo.html
Patterns discussion FAQ
http://gee.cs.oswego.edu/dl/pd-FAQ/pd-FAQ.html
Patterns in Java AWT
http://mordor.cs.hut.fi/tik-76.278/group6/awtpat.html
Software Technology's Design Patterns Page
http://www.sw-technologies.com/dpattern/
Previous Design Techniques articles
http://www.javaworld.com/topicalindex/jw-ti-techniques.html
Advertisement: Support JavaWorld, click here!
HOME | FEATURED TUTORIALS | COLUMNS | NEWS & REVIEWS | FORUM | JW RESOURCES | ABOUT JW | FEEDBACK
Copyright ?2003 JavaWorld.com, an IDG company
本文地址：http://com.8s8s.com/it/it1819.htm