Object Oriented - Correct Design/Layout - Questions
Hi, I’m still very new to C++ but want to keep my coding style to OOP. I want to practice perfect OOP design but need help and got some questions.
1) Lets say I am coding some game related program like a game hack. If I want to make it OOP design what would be the first main class to make? Would it be called Game Hack Manager? And what should I have in that class?
2) Also lets say I am making a console word guessing game following perfect OOP design. What would be the first main class to make? Would it be called Game Manager aswell or Game? What members would the class have? Also after that what other classes to make?
I’m just stuck at making the first main class. If that makes sense.
3) If anyone has more tips please feel free to comment!
Thanks!
1) Lets say I am coding some game related program like a game hack. If I want to make it OOP design what would be the first main class to make? Would it be called Game Hack Manager? And what should I have in that class?
2) Also lets say I am making a console word guessing game following perfect OOP design. What would be the first main class to make? Would it be called Game Manager aswell or Game? What members would the class have? Also after that what other classes to make?
I’m just stuck at making the first main class. If that makes sense.
3) If anyone has more tips please feel free to comment!
Thanks!
I'd go for Game being the main class. A (separate) Menu class which is subordinate to/separate from/relies on the Game is not a bad idea.
'Manager'/'Controller' are not impossible but are class names to be wary about.
https://softwareengineering.stackexchange.com/questions/129537/can-manager-classes-be-a-sign-of-bad-architecture
'Manager'/'Controller' are not impossible but are class names to be wary about.
https://softwareengineering.stackexchange.com/questions/129537/can-manager-classes-be-a-sign-of-bad-architecture
| I want to practice perfect OOP design but ... |
I don't think that's possible. But your OOP design will get better with experience.
I would suggest you start a design and see where it gets you. Don't be afraid to split some classes into parts or combine some classes into a one. As you go, you will see similarities in classes that might be captured well with a common base class.
So, my advice is don't be paralyzed by wanting to have a perfect design. Instead, come up with any design, and then refine it as you go. Sometimes designs change during implementation. If done poorly, sometimes designs change during testing.
Spend as much time as you can on refining your design during the design stage, and you will make your job easier down the road. But that doesn't mean there is only 1 perfect design.
| I’m just stuck at making the first main class. If that makes sense. |
A class defines the set of values a particular type can hold. The class Game represents, by definition, the set of every game - but how can you define the set of all games before you know what a single game is?
A main class for the whole application doesn't address any current problem. The whole application is the whole problem, and you will gain nothing by making it an object.
Only write classes if the need for an object is identified. Start by breaking the problem down to figure out how data moves through your program. Objects represent particular data sets; you can't define classes effectively until you understand the data and what will be done with it.
Classes are not a tool to break down problems. Classes define types of data. Single inheritance specialize types of data.
Depending on how much depth you want to go into, try:
https://lmgtfy.com/?q=game+programming+patterns
UML is another great project planning method showing the Game encompassing its Actors and Interface classes plus all the others into the OO context very easily. and succinctly. Again it depends on the complexity of the Game, depth of planning and project analysis required before coding starts.
You'll probably see a very simple Game concept with Only a single Actor and Menu becomes almost unmanageable without proper planning.
https://lmgtfy.com/?q=game+programming+patterns
UML is another great project planning method showing the Game encompassing its Actors and Interface classes plus all the others into the OO context very easily. and succinctly. Again it depends on the complexity of the Game, depth of planning and project analysis required before coding starts.
You'll probably see a very simple Game concept with Only a single Actor and Menu becomes almost unmanageable without proper planning.
As an example, a hypothetical Game might be broken down as follows:
Games have Actors
An Actor is a Soldier, Civilian, Weapon
Games also have Interfaces
An Interface has an Input
An Interface is a Console_Menu
An Interface is a Window_menu
A Game has a State
... and that can be modelled and expanded as required into components adopting inheritance and composition and all the rest of the OO toolbox.
Games have Actors
An Actor is a Soldier, Civilian, Weapon
Games also have Interfaces
An Interface has an Input
An Interface is a Console_Menu
An Interface is a Window_menu
A Game has a State
... and that can be modelled and expanded as required into components adopting inheritance and composition and all the rest of the OO toolbox.
Topic archived. No new replies allowed.