• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Nicholas Kong

Critique my Java Class Names

16 posts in this topic

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.

 

[url=http://s33.photobucket.com/user/warnexus/media/JavaClasses_zpsad033fab.png.html]JavaClasses_zpsad033fab.png[/URL]

Edited by warnexus
0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


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

Share this post


Link to post
Share on other sites

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
1

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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. 

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0