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?

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

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • ""thinger" - the class that gets things done, changes game state. " Why wouldn't you just call that class Game? – John Wu Dec 6 '18 at 20:54

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.

  • 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.

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