I am pretty new to Java and I am trying to get my hands around OOD.

In the course of designing a GUI, I am working on breaking down the
components into the necessary objects so that the code will be as
versatile as possible.

As I work through it though, I am confronted with the situation where
I feel that I am over analyzing and creating too many objects.


Let's say that I have a pretty basic window application.  It has a
window with a menu bar and three menus, each with a few items.

The main window is an object inherited from JFrame.  

Is it best to make the menu a seperate object, inherited from
JMenuBar, and then make each menu a seperate object, inherited from
JMenu, and then make each menu item a seperate object, inherited from
JMenuItem?  Or, is a lot of this typically placed within a single,
larger object?

I guess I am wondering where you draw the line.  How do I know when I
have gone too far and am creating too many objects unnecessarily?

I imagine a lot of this dicussion is personal preference and some
aspects are open to debate.  I am just looking for some guidance as I
learn more about this.

Thanks.

J.Storta wrote:

> [...]
> The main window is an object inherited from JFrame.  
> 
> Is it best to make the menu a seperate object, inherited from
> JMenuBar, and then make each menu a seperate object, inherited from
> JMenu, and then make each menu item a seperate object, inherited from
> JMenuItem?  Or, is a lot of this typically placed within a single,
> larger object?
> 
> [...]

I recommend to use JFrames, JMenus, JMenuItems
instead of extending them. Only if you extend or
override behavior in these classes (rarely needed)
you should subclass these Swing classes.
    This is much like *using* a HashMap, ArrayList
instead of extending it.

You can *build* your user interface, either
with builder classes or builder methods.
For example you can use methods like #buildFrame,
#buildMenuBar, #buildFileMenu, #buildHelpMenu, etc.

Then separate concerns and split up and group
methods, classes and roles like you are used to
when creating classes in the domain object layer.

- Karsten Lentzsch

On 12/5/2004 at 10:40:21 PM, J.Storta wrote:

> As I work through it though, I am confronted with the situation where
> I feel that I am over analyzing and creating too many objects.

> Is it best to make the menu a seperate object, inherited from
> JMenuBar, and then make each menu a seperate object, inherited from
> JMenu, and then make each menu item a seperate object, inherited from
> JMenuItem?  Or, is a lot of this typically placed within a single,
> larger object?
> 
> I guess I am wondering where you draw the line.  How do I know when I
> have gone too far and am creating too many objects unnecessarily?

No matter what, unless you do some really strange things, you are going to
create a separate *object* for each menu bar, menu, etc.  I think you mean
to ask whether you should define subclasses of JMenuBar, JMenu, etc.

The distinction is important, because creating too many unnecessary
objects can be a performance issue, although not with the number of
objects you are talking about here.  Whether to define subclasses is a
code organization issue.

One of the primary goals should be to organize your code in manageable
chunks that serve a single coherent purpose.  You do not want to have
classes with many thousands of lines of code that do everything under the
sun.  At the same time, you do not want the code for a single purpose
split up across many different files.  Doing this can make your code
difficult to manage as well.

With larger programs, I sometimes define a JMenuBar subclass, generally
when I end up with something more than just a simple list of add() calls.
But if that is all my menu-related code does, and if the code is
relatively short, I will just include it in with the top-level UI code.

There are some rare occasions for defining a subclass for just one menu,
such as one that will be usable in multiple programs.  For example, I have
a LookAndFeelMenu in one of my class libraries that automatically
populates itself with a menu item for each of the available
look-and-feels.  But except for cases like that, I would rarely define a
separate class for each menu.  That just makes your code hard to follow.

-- 
Regards,

John McGrath

Thank you for your responses.

That lets me know that I was on the right track in thinking that I was
taking my analysis a little too far for a small application.

Unless I have a need to customize a library object (JMenu, JMenuItem,
etc..)  I will incorporate the relevent code into my frame object and
then organize everything using methods.

Thanks again.