This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.

Message:

Beanification

Posted by Mark Johnson on 22 Sep 1998, 10:59 AM

> Some objects
> are holders for algorithms (say, the Math object in java.lang),

java.lang.Math is a class, but there is little reason to call
it an "object". While you could create an instance of it, it
has no non-final fields and no nonstatic methods.
You might conceivably create instances of subclasses
of java.lang.Math that, for example, implements all the operations
in terms of BCD math, or something, but since you can't
override the static methods, that would be sort of useless.
Certainly this is a class that shouldn't be a Bean.

Classes that contain only methods can make excellent
Beans, though. You might have an ObjectList
GUI element which presents a list of objects, and defers
sorting to an algorithm encapsulated in an subclass
of ObjectListSorterBean. This bean has only
a single method (compare()) and no fields.
If you serialize this object, you just get an empty stub,
but that's no problem. You can create subclasses of ObjectListSorter
to sort in various ways, and then connect your list
(graphically) to its ObjectListSorterBean to change its behavior.
When you Serialize the list, the sorting customization gets
saved automatically. And the ObjectList bean is
extensible (at least in terms of how its objects can be
sorted) without modifying the list class. So there's an example
of a "methods-only" bean that makes sense as a bean.
(This pattern is called "Strategy" in the Gang of 4 book.)

> and some objects have no concept on what it means to be saved
> (say, for instance, a Transaction object which may have run-time
> sense, but not necessarily persistant sense).

Actually, I think there's a good argument for making your "Transaction"
object Serializable, at least client-side. The type of object you're
describing is called, in Enterprise JavaBeans, a "Session" bean.
Session beans can be asked to return a "handle", by which
a new client-side session bean can be created elsewhere that is
connected to a Session EJB component resident on a particular
server. So you can partially fill out a form, bookmark the page
(with the Session bean handle embedded in the bookmark
URL), reboot your machine, and then "visit" the "same page".
The server would reconnect you to your existing Session
component, identifying it by handle. So, "Serializable"
in this case, for your client-side bean, would mean
serializing to the *handle*, not to the contents of the object.
This is a more abstract form of "Serializable"--it's serializing
a reference to a dynamic instance of something.

This is especially useful if you're writing a distributed app
that uses something like RMI to pass these handles around.
Then you want very much for the session bean to be Serializable,
because if it's not, it won't make it to any system other than
your local client.

> The main worry that I have re: beanification is implementing the
> Serialisable interface. In my mind, the Java spec hasn't got it
> right in the saving/loading of objects, but that isn't the issue here.
> The problem is that marking an object as Serialisable may do more damage
> than it is worth. Consider the following:

> public MyClass implements Serializable {
> Image anImage = new Image();
> }

> Now, although this object declares itself to be serializable,
> in practise it isn't. This kind of hand-wavy-error just to gain
> a Bean(TM) stamp on it results in seriously difficult to debug
> code, especially if a decent IDE points out all the non-transient
> non-serialisable instance variables.

I'm not sure how different this is from complaining that
Java lets you:
int i = 1;
int k = i - i;
int j = 1/k;

Certainly you shouldn't claim that classes are Serializable if
they aren't! But in the case of your contains-an-image class,
it may or may not be worth the effort (depending on your
application) of overriding readObject() and writeObject()
so that the object truly is Serializable. Or, as you say,
deciding not to (recognizing that you're closing the
door to Beandom, at least for the time being.)

> The issue is that you shouldn't say you're Serializable unless you're
> sure you *are* serializable. Most people will not test this,
> especially if they are just writing an object which they never
> expect to save.

Well, again "saving" isn't the only use of Serialization. There's
also network portability (RMI) and clipboard operations.
But your point is, why require "Serializable" classes that will
never be used that way. If they're never used that way,
then you'll never get those exceptions, right? And if you
*do* get the exception, then obviously someone's trying
to serialize something you think shouldn't be. In either case,
you're going to have to make a decision.

> If The Great Book Of Coding Standards says that
> you should create a class with 0-arg constructor and implement
> the Serializable interface, then we've lost the point of it
> anyway ... instead, we'll have a whole bunch of objects which
> are marked Serializable but which trash your IDE all the time
> with NotSerializableExceptions all over the place.

> This is even more noticable with sub-classes;

> public MySubClass extends MyClass {
> Image iDontCareAboutBeingSerializable;
> }

> The point: class heirarchies, signatures and interfaces should
> be designed, and decided on if a class is Serializable rather
> than a coding convention. Yes, it is a good idea -- but only
> if coders understand the consequences.

Yeah, it all comes down to whether coders understand what
they're doing. And you're right, a good IDE should refuse
to use Beans that claim to be Serializable but aren't.
It's too bad there's no way to catch that big ol' lie at
compile time! That probably is a design weakness of JB.

--Mark Johnson
JavaWorld