Back to General and Gameplay Programming

Critique my Java Class Names

Nick · 2013-09-24T08:46:57

I just want to know if the Java Class Names are appropriate so that when someone sees the class they will know what the class does based off the name. The game is a "match the word to the displayed image" type game.

General and Gameplay Programming Programming

Started by Nicholas Kong August 31, 2013 12:13 AM

15 comments, last by Ronnie Mado Solbakken 10 years, 6 months ago

Sacaldur

943

September 04, 2013 12:58 PM

I have no idea what's the purpose of your classes so I can't say if their names are good.
I'll guess around the classes purposes, maybe it'll help a bit:

Main - the applications entry point (main method): ok
Game - represents the game the player is playing: ok
GameComponent - a base class for components for the game, but what components exist? ok
Vector2D - a vector of 2 elements: ok
Sprite - represents an image or an "instance" (reference to the image and informations about the screen position): ok
CorrectMarkImage - an image for "that's correct", should just be a sprite, the naming is ok, though
PressLogo - an image containing the press/publishers logo, should just be a sprite, the naming is ok, though
WrongMarkImage - an image for "that's wrong", should just be a sprite, the naming is ok, though
Letter - contains a single letter and maybe also some other game related informations, seems to be an important part of you game: ok
Word - contains multiple Letters and maybe also game related stuff, seems to be important for the game, too: ok
WordGenerator - generates words: ok
WordChecker - checks if a word is correct/good, game logic stuff: ok
WordCompletionSystem - I have no idea... it completes words?
CorrectWordTextGenerator -
FileHandler - handles files... whatever this one means... ok
GameControlArt - art (images) for the GameControls? If so: should be some kind of a Sprite (in my opinion)
ImageGenerator - generates images... why? most images I'm using are loaded, not generated. What kind of images are generated? But the naming is ok
MainMenuArt - same as GameControlArt for the MainMenu
MainMenuSystem - shouldn't it be a general "MenuSystem"? But I can deal with it...
ModeSelection - is used while the (game?) mode is about to be selected, but is it a (sub)menu? or a control within a menu?
PlayerScoreGenerator - generates the players score... but wait: doesn't the player gain points while playing?
ScoreKeeper - stores the scores (temporary or persistent): in my opinion is "ScoreKeeper" not very well, whats about "ScoreStorage" oder in short "ScoreStore"? (I don't know why, but now I want to play "Dungeon Keeper"... ^^)
ScoreTextGenerator - generates the score text? I hope you display some funny messages for different scores, therwise I wouldn't get this one...
SelectionMarker - the highlighting of a selected text (in an input field): do you really need a class for that? ok
TimerTextGenerator - formats the time?
NumericTimerGenerator - generates numeric timers (roman number timers are so uncool)
UnderscoreGenerator - generates underscores ("_ _ _")?

Without knowledge about the game it's hard to say if the naming is ok.
And you really should use packages!

Glass_Knife

8,637

September 04, 2013 03:55 PM

I think package names would really help to classify you code. For example, take the TimerTextGenerator class. I would expect different behaviors based on the package. It's in the game.text package: deals with text. It's in the game.art package: maybe it creates a ticking clock? It's in the game.utility package: probably just a helper class.

As your stuff gets large, and you pass 100 files, it becomes easier to manage.

Also, pay attention to the package scope for method names. If you don't use public, protected, or private, then those methods can be seen only by classes in the same package. This is great for hiding classes and methods from other sections of code. If all the text classes that are only used by other text classes only have package scope, then when you use code completion in your IDE, but you're in the main game, all those classes will be hidden.

I think, therefore I am. I think? - "George Carlin"
My Website: Indie Game Programming

My Twitter: https://twitter.com/indieprogram

My Book: http://amzn.com/1305076532

Bacterius

13,181

September 04, 2013 04:08 PM

I think package names would really help to classify you code. For example, take the TimerTextGenerator class. I would expect different behaviors based on the package. It's in the game.text package: deals with text. It's in the game.art package: maybe it creates a ticking clock? It's in the game.utility package: probably just a helper class.

As your stuff gets large, and you pass 100 files, it becomes easier to manage.

Also, pay attention to the package scope for method names. If you don't use public, protected, or private, then those methods can be seen only by classes in the same package. This is great for hiding classes and methods from other sections of code. If all the text classes that are only used by other text classes only have package scope, then when you use code completion in your IDE, but you're in the main game, all those classes will be hidden.

+1 for packages, even for small projects it helps a lot and adds additional logic to what should interact with what, through imports as well. If you have everything in the same package, every class sees every other. Whereas if you have packages split across, for instance, containers, logic code, and interface code, while working out the necessary imports you sometimes go "wait, do I really need this to interact with that? maybe I should sit back and rethink what this class does" instead of just brute-forcing your way ahead and creating spaghetti code as you go.

Don't start putting every class in its own package, though.. that's just the worst of both worlds. Be reasonable, packages are supposed to help, not be a hindrance.

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”

Nicholas Kong

1,535

Author

September 04, 2013 10:19 PM

Thanks

I have no idea what's the purpose of your classes so I can't say if their names are good.
I'll guess around the classes purposes, maybe it'll help a bit:

Main - the applications entry point (main method): ok

Game - represents the game the player is playing: ok

GameComponent - a base class for components for the game, but what components exist? ok

Vector2D - a vector of 2 elements: ok

Sprite - represents an image or an "instance" (reference to the image and informations about the screen position): ok

CorrectMarkImage - an image for "that's correct", should just be a sprite, the naming is ok, though

PressLogo - an image containing the press/publishers logo, should just be a sprite, the naming is ok, though

WrongMarkImage - an image for "that's wrong", should just be a sprite, the naming is ok, though

Letter - contains a single letter and maybe also some other game related informations, seems to be an important part of you game: ok

Word - contains multiple Letters and maybe also game related stuff, seems to be important for the game, too: ok

WordGenerator - generates words: ok

WordChecker - checks if a word is correct/good, game logic stuff: ok

WordCompletionSystem - I have no idea... it completes words?

CorrectWordTextGenerator -

FileHandler - handles files... whatever this one means... ok

GameControlArt - art (images) for the GameControls? If so: should be some kind of a Sprite (in my opinion)

ImageGenerator - generates images... why? most images I'm using are loaded, not generated. What kind of images are generated? But the naming is ok

MainMenuArt - same as GameControlArt for the MainMenu

MainMenuSystem - shouldn't it be a general "MenuSystem"? But I can deal with it...

ModeSelection - is used while the (game?) mode is about to be selected, but is it a (sub)menu? or a control within a menu?

PlayerScoreGenerator - generates the players score... but wait: doesn't the player gain points while playing?

ScoreKeeper - stores the scores (temporary or persistent): in my opinion is "ScoreKeeper" not very well, whats about "ScoreStorage" oder in short "ScoreStore"? (I don't know why, but now I want to play "Dungeon Keeper"... ^^)

ScoreTextGenerator - generates the score text? I hope you display some funny messages for different scores, therwise I wouldn't get this one...

SelectionMarker - the highlighting of a selected text (in an input field): do you really need a class for that? ok

TimerTextGenerator - formats the time?

NumericTimerGenerator - generates numeric timers (roman number timers are so uncool)

UnderscoreGenerator - generates underscores ("_ _ _")?

Without knowledge about the game it's hard to say if the naming is ok.
And you really should use packages!

Ah I see what you mean...probably will use Sprite as the suffix.

Irlan Robson

4,091

September 23, 2013 11:50 PM

About the class naming convention, the code is normal.

Just don't use "Something Class", "Something Manager", "Something Object", etc. because they already are and if you are using them there is a problem with your design.

Nicholas Kong

1,535

Author

September 24, 2013 04:23 AM

About the class naming convention, the code is normal.

Just don't use "Something Class", "Something Manager", "Something Object", etc. because they already are and if you are using them there is a problem with your design.

Thanks for the heads up. I do try to avoid ambigous, obvious and vague class names.

Ronnie Mado Solbakken

610

September 24, 2013 08:46 AM

Should also just generally avoid redundant classes, for that matter. Always try to find ways to standardize and re-use already written code instead of writing it twice or more.

Inheritance is your friend.

- Awl you're base are belong me! -

- I don't know, I'm just a noob -

Critique my Java Class Names

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Critique my Java Class Names

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines