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
