Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top


I'm working on coding a few light-weight touch-tablet games and often get stuck with difficulties naming my user interaction/interface classes and their relationships with each other (architecture?). I'm rarely satisfied with any of my solutions, thus doubt and change them several times on down the line. For example, I have a board game with these components (among others):

  • "HUD" - the HUD frames the view of the game world thus enabling user interaction
  • "boardOverlay" - this is invisible and lies on top of the viewed game world. It receives and interprets touches, consequently calling methods in "thinger".
  • "board" - maintains all elements on the board.
  • "thinger" - the class that gets things done, changes game state. I call it thinger since I dont know what it should be called. Better to have a non-descript name than one that will be misinterpreted.

Searching for enlightenment:

Now I would like to have general/abstract names/architecture for these components which will likely be used in many other games/apps. But I have difficulty coming up with satisfying ones. I have searched the net many a time for guidelines/advice but I find that all of the sources are language/technology/API specific and seldom like their approach.

I don't know the name of this discipline/practice to search for for enlightenment. I have tried "event driven framework", "event driven naming conventions", "GUI architecture", "+oop +GUI +taxonomy"... on and on .... .... with no luck.


Can anyone provide a resource to enlighten me? A technology independent resource that philosophizes about this type of naming and architecture.

Extra credit question:

It would also be great with a reliable/concise resource discussing practices/disciplines of this context? There are too many different and overlapping usages/interpretations out there. Example: GUI framework, GUI architecture, GUI structure, GUI design - what should the proper usage of these terms be?

share|improve this question

closed as too broad by Scant Roger, gnat, Ixrec, MichaelT, Dan Pichelman Dec 28 '15 at 19:13

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Have you heard about the Model View Controller (MVC) Architectural Pattern? Maybe it would help you to name things clearer if you apply this pattern to your software architecture/design.

If i would apply this pattern to your components i would do it like that:

  • HUD = Hud View

  • boardOverlay = Board Controller

  • board = Board View if it's main task is rendering, Model otherwise

  • thinger = Game Controller

Hope this helps.

share|improve this answer
Just what I was looking for. "Architectural Pattern" is just right. My HUD however will offer touch input as well as provide output. So I will have to think about whether "view" is the right pattern for that. Thank you much JoR. – Amoxus Feb 19 '12 at 10:50
Thanks. You could create a HudView for rendering the actual values of the HUD and a HUDController for getting the inputs. – JoR Feb 21 '12 at 15:53

If not by MVC, maybe you can separate them logical layers and name them as such? GUI, Middleware, DataAccess, Security, etc.

Personally, I would try and follow an architectural pattern or see if your implementation fits any existing pattern. From there you can use their naming structure and go from there.

share|improve this answer
Architectural pattern it is. Thanks johnofcross. – Amoxus Feb 19 '12 at 10:51

Not the answer you're looking for? Browse other questions tagged or ask your own question.