Jump to content
  • Advertisement
Sign in to follow this  
Nicholas Kong

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

This topic is 1851 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Suppose you had to write a class that holds a health system and item system for a game. What would you call the class? I am writing the code in Java. I came up with a name called TopGUI because the GUI is going to be placed on top of the game that holds these two systems. But I figure the name is going to raise a lot of red flags for any people looking at my own code in the future. I need suggestions. rolleyes.gif  

Share this post


Link to post
Share on other sites
Advertisement
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?

Share this post


Link to post
Share on other sites

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. 

Edited by warnexus

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Edited by warnexus

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!