|
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:
To Bean or Not To Bean
Posted by Alex Blewitt on 17 Aug 1998, 4:08 AM
Hi yall. I've just looked through the forum on your beanification column,
and wanted to put forward an idea of mine which I've come up with
with regards to Beanification. I think that it's a good idea that most objects can be treated
as Beans. I think that sometimes it is not necessarily the case
that *all* objects should be treated as beans though. Some objects
are holders for algorithms (say, the Math object in java.lang),
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). 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. 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. 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. Hope that helps, Al.
Replies:
|
