Is this swing OO Design possible?
Hi Guys
Ive come up with a design for my GUI and I was wondering if it is possible (all seems possible in UML) to actually implement as a solution in java.
The idea is to have an interface that will provide a set of commands that a GUI class and its subclasses can implement individually. But as a whole implement the interface correctly.
The Ingredients:
Class1 -> An interface that has methods that will do some work e.g. remove items.
Class2 -> A GUI Form that implements Class1
Class3 and 4(subclasses) -> All GUI Dialogs that extend Class2
The Uncertainty 1
Can subclasses 3 and 4 implement methods from an interface (Class1) that is implemented by Class2(parent)?
Can all the subclasses implement different methods from the interface or does each subclass have to implement all the methods again?
The Uncertainty 2
Is it possible for an anonymous inner classes within the subclasses(class 3 and 4) to implement the methods from the interface?
Is it possible, any help or clarification with this would be great
Cheers
[1137 byte] By [
FatClienta] at [2007-11-26 19:22:09]
> Can subclasses 3 and 4 implement methods from an
> interface (Class1) that is implemented by
> Class2(parent)?
They can override the methods so long as they are non-final.
> Can all the subclasses implement different methods
> from the interface or does each subclass have to
> implement all the methods again?
A subclass could override only those which it needs to so long as the superclass has implemented the rest.
> Is it possible for an anonymous inner classes within
> the subclasses(class 3 and 4) to implement the
> methods from the interface?
Yes.
Why not make up a small experimental interface and see? It should take less time that it took to compose your question!
I did the experiment, and it gave a compiler warning:
Parent.java:3: Parent is not abstract and does not override abstract method Num3() in Controller
The Interface class:
public interface Controller
{
public String Num1();
public String Num2();
public String Num3();
}
The Parent(superclass)
public class Parent implements Controller
{
public Parent() { }
public String Num1()
{
return "parent";
}
}
The two child(subclasses):
public class Child1 extends Parent
{
public String Num2()
{
return "child1";
}
}
public class Child2 extends Parent
{
public String Num3()
{
return "child2";
}
}
The main method:
public static void main(String[] args)
{
Parent myParent = new Parent();
System.out.println(myParent.Num1());
Child2 myChild2 = new Child2();
System.out.println(myChild2.Num3());
Child1 myChild1 = new Child1();
System.out.println(myChild1.Num2());
}
so, whats wrong with this, according to you pros, its all possible, but how come the compiler says that the parent class needs to be abstract?
im sure its a simple noooobian mistake, but nooob i am
Nobody ever said that you don't have to implement the entire interface. We just said that the subclass doesn't have to, but that implies the superclass will be required to either be abstract or implement all of them.
****!
So will I just have to live with empty methods in the subclasses, that do not implement all the remaining methods e.g
public class Child1 extends Parent
{
/** Creates a new instance of Child1 */
public Child1() {
}
//overiden - actual method needed
public String Num2()
{
return "child1";
}
//nulled method
public String Num3()
{
return null;
}
public String Num1()
{
return null;
}
}
Is that allowed?
Why wouldn't it be allowed? You can put whatever code you like into a method.And what happened when you tried it?
Yes, it worked (blushing)I was just thinking that there might be a better solution then having extra methods that don't really do a thing. All you pro's should get a T-shirt that says "I Told you so", so when retards like myself ask dumb questions, All you do is point!
> I was just thinking that there might be a better
> solution then having extra methods that don't really
> do a thing.
There's no hard and fast rule. Such a case could indicate the interface is overly ambitious, or that your object doesn't really fit the interface. Maybe the superclass can provide default implementations and the subclasses can override what they need to. I don't really know because it's too generic, however empty methods are not uncommon, especially with listeners. Listeners often define multiple callbacks whereas a particular implementation may only care about dealing with one of them. In Swing you'll often find a skeleton implementation meant to deal with it:
// Interface defining callbacks for a mouse listener
public interface MouseListener {
public void mousePressed(MouseEvent e);
public void mouseReleased(MouseEvent e);
public void mouseClicked(MouseEvent e);
}
// Does nothing but implement the interface so only those methods
// the subclass is interested in have to actually be implemented
public abstract class MouseAdapter implements MouseListener {
public void mousePressed(MouseEvent e) {}
public void mouseReleased(MouseEvent e) {}
public void mouseClicked(MouseEvent e) {}
}
public class MyMouseListener extends MouseAdapter {
public void mouseClicked(MouseEvent e) {
// This is the only callback we care about dealing with
}
}
Aside: is MouseAdapter a good name for that class? It's certainly not the Adapter Pattern! What would you call it, if it were up to you to name it?
Hmm...I would call it...TheMouseListenerMethodImplementationClassSoThatYouAreNotRequiredToImplementAllTheMethods classwell, maybe... :-p
> I was just thinking that there might be a better
> solution then having extra methods that don't really
> do a thing.
Well, yeah, there might be a better, or different, design that doesn't make you do that. But when you have to implement an existing interface and you want to say "Don't do anything when this happens" then what do you put in that method? Nothing!
> Aside: is MouseAdapter a good name for that> class? > It's certainly not the Adapter Pattern! > What would you call it, if it were up to you to name> it?There's many of them in Swing, I've never bothered to analyze the name.
> > Aside: is MouseAdapter a good name for that
> > class?
> > It's certainly not the Adapter Pattern!
> > What would you call it, if it were up to you toname it?
>
> There's many of them in Swing, I've never bothered to analyze the name.
Okay. If you were writing one today, in some Swing-related code you might be
tempted to name it FooAdapter, let us say.
But suppose you are writing such a class in some neutral context.
Is there a better name for it? For example, I would have given
MouseAdapter the name DefaultMouseListener.
I was wondering if forum members had any other opinions, that's all.
> Okay. If you were writing one today, in some
> Swing-related code you might be
> tempted to name it FooAdapter, let us say.
>
> But suppose you are writing such a class in some
> neutral context.
> Is there a better name for it? For example, I would
> have given
> MouseAdapter the name DefaultMouseListener.
> I was wondering if forum members had any other
> opinions, that's all.
I'd probably just call it AbstractMouseListener. Generally when I have "DefaultX" it's literally a default implementation of X, not an abstract skeleton class meant to facilitate an implementation. I don't really have a problem with using "XAdapter" either since, while it is a stretch, it does serve a similar purpose of molding one interface to another, but it's not quite the same.
Good points. You know, I never noticed that all those Swing *Adapter classes were abstract, until this moment. As for the name, I was thinking of org.xml.sax.helpers.DefaultHandler.
