MaydenCompe MaydenCompe - 3 months ago 8
Java Question

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

//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

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.

Comments