Coming up with a class name for an object that holds things

Why does this class even exist? Why does it need to hold both a health and an inventory system? What does that even mean? Is it tied to the player, arbitrary characters in the game, or none of the above? What on earth does the GUI have to do with any of this?

Hi Apoch! I guess I should use the word "adds" instead of hold. It would exist so you can easily remove the GUI that holds the two systems more easily in the constructor from the Game class. I have not written a class that does such a thing. I just wrote the thread to see if it is worth the effort. As it stands right now, it exists as a created JPanel object that adds the two systems in the Game class's constructor instead of creating a class and inherit from a JPanel and then have the two systems be added to it. Based on your feedback, it is the wrong way to go about it.

I am creating an arcade shooter game. The ship has a health system and also uses the item system when it collects item drops from the monsters it shot.

I wrote the Health System and Item system so they are inherited classes from Java's JPanel class. That way I can have both the two systems be placed on another JPanel object called topGUIPanel because in Java objects inherited from the Component class can be added to a JPanel object which also inherits from the Component class.

The Item System are displayed on the left side of the game window. The Health System is displayed on the right side of the game window.

Ah, I see.

I would suggest splitting your UI implementation away from your game implementation as much as possible. Look into paradigms like Model/View/Controller for inspiration on ways that might be done.

Ah, I see.

I would suggest splitting your UI implementation away from your game implementation as much as possible. Look into paradigms like Model/View/Controller for inspiration on ways that might be done.

But when the game loads which is when the game constructor gets called, the game has to load the GUI components(ie: health system and item system). I thought this would be a convenience.

Single Responsibility Principle states that each class should have one responsibility, and it should fully encapsulate that responsibility. There are times when you might have to view this as more of a guideline than a hard-and-fast law, but it is still something you should carefully consider.

But when the game loads which is when the game constructor gets called, the game has to load the GUI components(ie: health system and item system). I thought this would be a convenience.

It won't be a convenience, not when your game gets sufficiently complicated that this class grows into a DoEverything sort of class. Then it will be a blasted nuisance.

You should try to break your DoEverything classes down into their component bits. If you have a class named TopGUI that handles the health as well as the items, you have a vastly over-broad class that is handling far more than a single responsibility. Break it down, compartmentalize, study the patterns (such as MVC, which Apoch mentioned) and figure out how to apply them to your problem.

Note: A good indication that your class is overly broad is the fact that you are having difficulty finding a name for it. Elegant classes should usually be easily named because their responsibilities are clearly delineated.