With OOP should methods be turned into objects as frequently as possible?

Question

//OOP = Object Oriented Programming

I've played around with Java in the past and recently I've been diving deep into it and self-teaching OOP. I'm currently creating a text-based game and as I create methods to perform tasks I notice that if I wanted I could instead turn the methods into objects.

I don't know much about runtime or sparing resources so I can't necessarily take these variables into consideration, but for the sake of my code it seems like it may clear up some space here and there. However, on the flip side I will be creating numerous classes which I feel may clutter my directories.

~~ For example, I have created a separate class for creating the a profile for a player. In it, it has 3 significant methods. One for handling the player's name choice, one for handling the player's class choice, and one for finalizing the player's decision.

I could create 3 objects for these methods and call them through this class which may clear up space in the code, or I could leave them be.

Would it be more wise to create separate objects or just leave them be?

Answer 1

The best approach is the one that results in the code that is easiest to maintain, understand, and extend. The three methods you describe are probably in the right spot already, but it depends on what the class itself is supposed to represent.

You describe it as the profile for a player, and the three methods you describe all manipulate data that is unique to that profile, so your approach so far sounds fine.

The most important thing: Keep coding. Don't get hung up on details like this. They usually aren't as important as they seem from a textbook or classroom presentation, and they certainly aren't as important as the zealots who favor one approach over all others will lead you to believe. Code can (almost) always be refactored, and is (usually) never completely correct the first time around.

If anyone tells you that their way is the "best way" or the "right way" when it comes to questions like this, ignore them and seek advice from someone else.

Answer 2

If you don't have to create many instance of objects or you can handle it well, it is not necessarily changed your code style, unless you have to work in group and come to an agreement.

Also, I guess it is better for you to clarify what are "classes" and "objects" first via this link. Basically an object is created from a class, containing states and methods.

In your example, i see a controller view of class rather than object, have you heard of MVC? Please check this link if you don't, because it helps you clarify much more than you may have thought about "classes" and "model"

I hope i did not make you thought worse, but it is important to know what's going on.

Answer 3

Remember KISS ("Keep it simple, stupid"). You don't need to constantly be extracting everything into interfaces, super classes, multiple methods, etc. It's good to refactor, but when your code does something simple it should look simple too.

Answer 4

Reading through your question and other answers I would suggest a single profile class, that would deal with everything related to a profile. Though more information could help, feel free to post your code.

Careful with word choice, it can get confusing. When I say Profile class I mean a single Profile.java file containing the Profile class, with related methods and variables.

Your hypothetical Profile.java class would contain relevant variables such as profile name, class, maybe a boolean indicating that the decision has been finalized. Or you could just have the constructor take all that data once at the beginning after prompting the user?

Additionally you can have all those methods (eg handling name choice, class choice, getters and setters) you currently have separated into 3 different files in just this file. This can hopefully help simplify things so you can have everything in 1 place.

Answer 5

The answer is it depends.

In OOP, classes (which are objects when instantiated) are used to promote encapsulation and abstraction. See this SO post for more detail.

Abstraction is the idea that objects share common traits which is demonstrated through class hierarchy (a IS-A b relationship) and class composition (a HAS-A b relationship).

Encapsulation is the idea that common state and its interaction should be seen as a single unit (or class) with well defined inputs and outputs, where the internals hidden within a class that represents it.

At the end of the day, OOP is meant to make coding easier for the programmer. This means less mental overhead trying to determine the interactions within the program, and visibly cleaner, easier to understand, code.

---

Case Study

In your case, you have a class that handles the player profile creation, let's call it PlayerProfileManager. According to encapsulation, all behavior (ie. methods) directly related to creating the player profile should be in PlayerProfileManager.

Looking at abstraction is where things get interesting.

PlayerProfileManager creates player profiles and stores that information somewhere. It probably makes sense to make a PlayerProfile class that holds all the data for a player profile, and then have PlayerProfileManager store a collection of PlayerProfile objects internally. Call them the profiles it manages.

PlayerProfileManager HAS-A PlayerProfile

You interact with your manager to do all the getting and setting of profile data and the manager stores that data in profile objects.

But do you have other types of profiles?

If so, maybe you need a Profile class that has all the profile information any profile would need. Then PlayerProfile inherits from Profile, adding all the player specific data.

PlayerProfile IS-A Profile

And then you may want a ProfileManager class that has generic methods for managing generic profile data.

PlayerProfileManager IS-A ProfileManager

Now we can take advantage of polymorphism, a key technique in OOP. If you wanted to do something with all profile data, you can do that very nicely with polymorphism because it all inherits from the Profile class. Read the link for more detail.

But always remember, abstraction only makes sense when it make your code easier to work with. If you only have one type of profile (and only plan on ever having one type), it doesn't make sense to add in the extra layers, as they are cluttering up your code, rather then cutting down on it.

---

Conclusion

There is no right answer, as long as the code is clean, and things that belong together are together (related to separation of concerns).

I encourage you to play with different levels of abstraction to figure out the advantages and pitfalls of too much or too little.