Jump to content

  • Log In with Google      Sign In   
  • Create Account


Critique my Java Class Names


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
16 replies to this topic

#1 warnexus   Prime Members   -  Reputation: 1371

Like
0Likes
Like

Posted 30 August 2013 - 06:13 PM

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.

 

JavaClasses_zpsad033fab.png


Edited by warnexus, 30 August 2013 - 06:17 PM.


Sponsor:

#2 stanirya   Members   -  Reputation: 771

Like
0Likes
Like

Posted 30 August 2013 - 06:50 PM

Naming is kind of a subjective thing but your naming is fine. At least, it conforms to what's normally expected in a Java project, and your classes are CamelCase, don't use any IWeirdImpl notation, and are descriptive (as far as we can tell - for all we know, your WordGenerator might be your main loop :)).

 

Are you building for J2ME? Anything else and I'd use package names, for convenience and convention.



#3 TheChubu   Crossbones+   -  Reputation: 3629

Like
0Likes
Like

Posted 30 August 2013 - 06:59 PM

You should start to put things up in separate packages. For now you can see everything in a single list, but that wont last long. Besides, separating functionality in packages kinda enforces some decoupling, or at least makes you think how your classes are really coupled.


"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

 

My journals: dustArtemis ECS framework and Making a Terrain Generator


#4 warnexus   Prime Members   -  Reputation: 1371

Like
0Likes
Like

Posted 30 August 2013 - 07:17 PM

Naming is kind of a subjective thing but your naming is fine. At least, it conforms to what's normally expected in a Java project, and your classes are CamelCase, don't use any IWeirdImpl notation, and are descriptive (as far as we can tell - for all we know, your WordGenerator might be your main loop smile.png).

 

Are you building for J2ME? Anything else and I'd use package names, for convenience and convention.

I am using Java SE(Standard Edition). Thanks for the feedback. It is nice to know the names are great.

 

Actually the main loop is in the Main.java. The Game loop is in Game.java.

 

Actually, an instance of WordGenerator class is created inside the Game class because the game needs to generate a new word whether the user got the word right or wrong.

 

Okay I will try to use packages too.


Edited by warnexus, 30 August 2013 - 07:24 PM.


#5 PandaDragonThing   Members   -  Reputation: 311

Like
0Likes
Like

Posted 30 August 2013 - 07:19 PM

Depending on what i'm doing, i'll do it as you do. If I am working on a project with which I have a clear name for, i'll use a precursor of every function and class. Kind of like how OpenGL's functions have gl such as glScalef, though I don't care much for the data type indicator at the end. One of my recent projects I have been using clu and Clu; cluFunction and CluClass.



#6 warnexus   Prime Members   -  Reputation: 1371

Like
0Likes
Like

Posted 30 August 2013 - 07:21 PM

You should start to put things up in separate packages. For now you can see everything in a single list, but that wont last long. Besides, separating functionality in packages kinda enforces some decoupling, or at least makes you think how your classes are really coupled.

Thanks TheChubu. Yeah I will need to use packages now. biggrin.png



#7 warnexus   Prime Members   -  Reputation: 1371

Like
0Likes
Like

Posted 30 August 2013 - 07:27 PM

Depending on what i'm doing, i'll do it as you do. If I am working on a project with which I have a clear name for, i'll use a precursor of every function and class. Kind of like how OpenGL's functions have gl such as glScalef, though I don't care much for the data type indicator at the end. One of my recent projects I have been using clu and Clu; cluFunction and CluClass.

What do you mean by a precursor like a common prefix? So gl, clu and Clu will be your precursors in your case?


Edited by warnexus, 30 August 2013 - 07:27 PM.


#8 TheChubu   Crossbones+   -  Reputation: 3629

Like
0Likes
Like

Posted 31 August 2013 - 12:29 AM

The reason why OpenGL functions have types at the end is because C doesn't supports function overloading. Thus every function has to have a different name, no matter if the parameters are different among functions with the same name. I wouldn't suggest doing the same if your programming language of choice does supports overloading, and the IDE is nice enough to tell apart between different functions.


"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

 

My journals: dustArtemis ECS framework and Making a Terrain Generator


#9 stanirya   Members   -  Reputation: 771

Like
0Likes
Like

Posted 31 August 2013 - 03:29 AM

Since there are classes and packages in Java to "partition the namespace", in a sense, there is IMHO no good reason to use a common prefix for all classes in your project.

 

On J2ME projects putting all classes into the default package was an optimization once but on J2SE projects you should generally use packages. Note that they conventionally go like tld.yourdomain.yourproject.maybeyoursubproject.yourpackage.yoursubpackagesetc in order to avoid conflicts globally but you are not limited to this, you can of course use any package names you want.



#10 warnexus   Prime Members   -  Reputation: 1371

Like
0Likes
Like

Posted 03 September 2013 - 08:38 AM

Since there are classes and packages in Java to "partition the namespace", in a sense, there is IMHO no good reason to use a common prefix for all classes in your project.

 

On J2ME projects putting all classes into the default package was an optimization once but on J2SE projects you should generally use packages. Note that they conventionally go like tld.yourdomain.yourproject.maybeyoursubproject.yourpackage.yoursubpackagesetc in order to avoid conflicts globally but you are not limited to this, you can of course use any package names you want.

Thanks! I use packages too.



#11 Sacaldur   Members   -  Reputation: 419

Like
0Likes
Like

Posted 04 September 2013 - 06:58 AM

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!

#12 Glass_Knife   Moderators   -  Reputation: 3228

Like
1Likes
Like

Posted 04 September 2013 - 09:55 AM

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.  


Edited by Glass_Knife, 04 September 2013 - 09:55 AM.

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

#13 Bacterius   Crossbones+   -  Reputation: 7981

Like
0Likes
Like

Posted 04 September 2013 - 10:08 AM

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.


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#14 warnexus   Prime Members   -  Reputation: 1371

Like
0Likes
Like

Posted 04 September 2013 - 04: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. 



#15 Irlan R.   Members   -  Reputation: 1252

Like
0Likes
Like

Posted 23 September 2013 - 05: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.



#16 warnexus   Prime Members   -  Reputation: 1371

Like
0Likes
Like

Posted 23 September 2013 - 10:23 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.

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



#17 Malabyte   Members   -  Reputation: 583

Like
0Likes
Like

Posted 24 September 2013 - 02: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. wink.png


Edited by Malabyte, 24 September 2013 - 02:57 AM.

- Awl you're base are belong me! -

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





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS