inheritance/containment and beans...

I have an object whose functionality is spread out over 3 classes: an abstract base class with a contained GUI class and a concrete derived class. I want to make this into a java bean. Is this possible? All the examples I've ever seen do not have this functionality distribution. Here's what I have:

Base Class: basic RMI setup and event handling

GUI class: GUI elements to specify registry and service

Derived Class: concrete RMI methods (implements Remote)

In this way, I can have many types of concrete derived classes that implement some specific communication interface, without needing the RMI fundamentals. Ideally, I'd like to make the derived class the bean, and have it use the other classes as needed. Must I make all 3 classes beans, and hook them up via events?

thanks,

jpl

[846 byte] By [jplerxt] at [2007-9-26 3:08:18]
# 1

I've re-read your post a few times, but I'm still not sure what you're trying to do. It sounds like this (let me know if I'm wrong):

o You have a GUI which uses some abstract base class for remote calls (instantiated as a derived class)

o The derived class does all the RMI stuff

And it sounds as though this is to isolate the RMI code from the GUI, in case you want to swap out the transport mechanism for the calls (for example, to replace it with CORBA)?

Is this correct?

My own experiments with JavaBeans leads me to the conclusion that they are best modelled using containment as opposed to inheritance.

This is not so obvious in "invisible" beans, but with visible UI beans, it follows the containment aspect of UI design, a component is contained within a component, etc. etc. It is very hard, if not impossible, to visually design a component using inheritance because of various technology constraints. Also, an "event" based system is fundamentally between components, as opposed to a callback system based on inheritance and specialization. It seems clear to me that the designers of the JavaBeans specification had containment in mind.

As a result, I would probably recommend using containment on non-visual beans for consistency., even though there may be less issues with it during implementation.

You might find that interfaces + containment get you everything you need for a reusable system. For instance, you could delegate the calls to a class which handled the transport layer (RMI) via an interface. The instance of this class could be set on the UI via a property setting.

Hopefully this reply was on topic! I see your original post was back in August so no doubt you've worked around your initial problem. What did you decide?

Dave

dstuart at 2007-6-29 11:13:02 > top of Java-index,Desktop,Developing for the Desktop...