views:

239

answers:

2

Hello,

I'm developping a small UML Class editor in Java, mainly a personal project, it might end up on SourceForge if I find the time to create a project on it.

The project is quite advanced : I can create classes, move them around, create interfaces, create links, etc.

What I'm working on is the dialog box for setting class/interface properties and creating new classes/interfaces.

For example, I have a class that extends JDialog. This is the main "window" for editing classes and interfaces (well, there a class for each). It contains a JTabbedPane which in turn contain JPanels.

This JPanel are actually custom ones. I created an abstract class that extends JPanel. This class uses components (defined by its subclasses) and add their values to a JTable (also contained in the JPanel).

For example, if I want to edit a class' attributes, the JPanel will contain a JTextField for entering the name of the attribute as well as another one for entering its type. There is also a set of button for processing the data entered in these fields. When I click "Save", the data I entered in the JTextFields are added into the JTable (à la Enterprise Architect). The concreted class that extends the abstract one are responsible for defining control and deciding what do to with the data when a line is added or deleted from the JTable. The JTable management is, however, the responsability of the abstract class.

Here is my problem : in OO, a class has methods, and an interface has methods too. I told myself : I could use the same concrete custom JPanel (AttributesPanel (which extends the abstract JPanel class I created)) to store the methods for a class or and interface.

However, the class needs to keep a copy (as an attribute) of the class or interface I am working on. That way, when a method is added to it, I can call editedClass.addMethod() (or editedInterface.addMethod()). The problem is that I have no way of telling whether I work on a Class or and Interface.

The solution I found is ugly : keep an attribute editedClass and an attribute editedInterface in the AttributesPanel class. According to whether I am editing a class or interface, one of these attributes will be null while to other will not.

It is quite ugly if you ask me. In fact, I can hear my software engineering teachers in my head screaming in agony while burning (well, actually, freezing) in the ninth circle of Hell.

The quick way to fix this design problem would be to create an interface called "ObjectWithMethods", which my Class and Interface classes will implement. That way, I will only have to put an ObjectWithMethods parameter in my AttributesPanel class.

But does that mean that I should create a class named "ObjectWithAttributes", or "ObjectWithBlahBlah" ? I see some good "TheDailyWTF" potential here... Besides, I don't think I should modify my domain objects (a Class, Interface, Note, Relationship (for my UML editor)) or create an new Interface just for the sake of some UI consideration....

What do you think?

I you need more clarifications (because I am very tired right now and I tend to right quite badly (especially in English - my mother tongue is French) while in this state of mind...), just ask and I'll edit this question.

Cheers,

Guillaume.

+3  A: 

When I read your question it really seems like you are describing a place to use the visitor pattern.

The reason the visitor pattern should work here is an idea known as double dispatch. Your UI code will make a call and pass a reference to itself, then the class or interface ends up calling the original caller. Since the class or interface is the one making the method call it knows its own type and how to do the work specific to its type.

Of course, my description is insufficient to implement this technique so you'll want to read up on it. I think it is well documented. For example, I found this in about 2 seconds in java that should get you started: http://www.javaworld.com/javaworld/javatips/jw-javatip98.html

Jason Dagit
A: 

Visitor? I saw this pattern very quickly a year ago. I'll check it out, thanks!

Guillaume Gervais