Is there a rule of thumb about how granular an object should be in OO programming?

Question

I take part in school OO programming, and over the next few months, each assignment includes craps and vocabulary games such as jumble and hangman. In each task, we create a new class for these variables; HangmanWordArray, JumbleWordArray, etc. In the interest of reuse, I want to create a class (or a series of classes) that can be reused for my purposes. It's hard for me to understand how this will look, and I hope that my question will make sense ...

Suppose that the class (es) contains properties with accessories and mutators and methods for returning various objects ... words, letters, throwing dice. Is there a rule for how to organize these classes?

Is it better to keep one object in a class? Or group all the objects in one class, because they are all related as "the things I need for assignments?" Or a group by data type, so all numerical objects are in one class and all strings are in another?

I think I'm struggling with how a programmer in the real world makes decisions about how to group objects in a class or series of classes, as well as some questions and thought processes that I should use to create this type of design scenario.

Answer 1

Actually, it varies from project to project. There is no guaranteed “right way” to group anything; it all depends on your needs. It's about manageability, which means how easily you can read and update old code. If you can keep all your games in one class of "games", then there is nothing wrong with that. However, if your games are very complex with a lot of subtitles and variables, it might be easier to control them moving to their own class.

Thus, there are ways to group elements logically. For example, if you have many solo functions that are used for manipulation (char to string, string to int, html encode / decode, etc.), you may decide to create a class of "helper functions" to hold them all, Similarly, if your application uses a database connection, you can create a class to store and manage the general connection, as well as have methods for receiving query results and executing non-queries.

Some people try to break a lot. For example, instead of having the database engine mentioned above, they can create one class to create and manage the database connection. They will create another class, then use the connection class to process requests. Not that this method does not work, but it becomes very difficult to control when the elements are separated too small.

Not knowing exactly what you are doing, there is no way to tell you how to do it. If you reuse the same methods in every project, then maybe you can place them somewhere so that they can share. The best way I've found to figure out what works best is to simply try it and see how it reacts!

Answer 2

What I see, people do, breaking their objects and methods, until each method is just a handful of code; if any method exceeds a page of code, they will try to break the structure of the object further in order to reduce costs.

I personally have no objection to long methods if they are readable. I think the “one page limit” tends to create too much granularity and is more confusing than less. But this, apparently, is a modern fashion.

Just letting you know what I see in the wild.