• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Knute Snortum
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Ganesh Patekar
  • Frits Walraven
  • Tim Moores
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Stephan van Hulst
  • salvin francis
  • Tim Holloway

AbstractAction and custom abstract class  RSS feed

 
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, I realize this is probably more of a Java Language question but since it is in the context of SWING I thought I would post it here. I am having a problem with extending and creating abstract classes.
My original code looks like this:

And I use it like the following:

This is all nice and everything but I realized that the methods in NewMenuAction were going to need to be re-written in all my Action classes. So I had the bright idea of creating a BaseAction class to encapsulate the common good, you know, OO Programming? So I created a BaseAction class that looks like this:

So far so good until I try and use it. First, the Action class that subclasses BaseAction:

Nothing too remarkable there.
And now, when I try and use this class as:

I get the following error:

So I am wondering what I need to do to fix this. Any hints would be greatly appreciated.
Thanks.
 
author and iconoclast
Posts: 24203
40
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's kind of a pain, but constructors just aren't inherited. The best you can do is

and similarly for the other constructors in BaseAction. There's a lot of ugly boilerplate, but no duplicate code.
Another approach altogether that you might be able to use with less duplicate code would be some kind of MenuItemFactory. Instead of a constructor with four parameters, you could have factory method with four (or five) parameters, then that factory method could create the appropriate BaseItem subclass using a default constructor, and call the various methods that you're currently calling in the constructors, directly. i.e., something like (I'm omitting exception handling here)

Now BaseItem subclasses just provide a default constructor and implement doAction(), and you make one by doing something like

Does this make sense?
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your "boilderplate" option worked out great. But I think I like to Factory method you described and I think I might give that a go. I will let you know what I come up with.
Thanks.
[ October 27, 2003: Message edited by: Gregg Bolinger ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!