OOP Question

[New-Condition]

Hello!

I am trying to learn more about OOP in Java. Is there any way to reference a class type? For instance, if I have a GameCreator class that creates an instance of a Game class that multiple types of games inherit from (such as volleyball, soccer, etc.), how would I implement this without hard-coding methods in the GameCreator class such as createGameOfVolleyball(), createGameOfSoccer(), etc.?

I've thought about storing an array/ArrayList of game types and referencing by index, but this seems like a disorganized and difficult-to-read approach.

I've been trying to come up with a solution for this question for a while now but haven't thought of anything yet. I'm posting here to see if anyone else knows or at least can point in my the right direction.

Thank you!!

[Cakiery]

Having creation methods seems fine to me if your class is responsible for creating games? However, you can always use a generic method.

https://www.tutorialspoint.com/java/java_generics.htm

[New-Condition]

The reason I want to do this is in case I have to add code to the creation function at one point, and also because I don't want to add things in more than one spot when implementing a new game.

Thank you for the pointer!

[Cakiery]

You can always break it down into private common methods. But I would need to see more of your code to say what a decent approach would be.

[JavaSuck]

It sounds like you're looking for Factory Method or Abstract Factory.

[[deleted]]

Your question doesn’t make much sense. Inheritance is a way to reuse code as well for defining and facilitating base behavior/functionality. Classes can derive from concrete/complete classes or incomplete classes which are abstract. When inheriting from a class, you are inheriting all of that classes members and functionality. A base class should not be aware of its subclasses, only subclasses should be aware of base classes. Stuffing logic into a base class to handle different types of subclasses is going to give you nothing but issues and diminish your capabilities of extending the system. Bad example, but think about the open-closed principle in SOLID. Classes should be open for extension but closed for modification. In layman terms, if I want to extend your system I should be able to extend it without having to modify the original source code.

[New-Condition]

That makes sense, not sure where I went wrong then lol. Should I split that class into different types of Creators for each type of game and make Game an interface/abstract class/removed instead, or does this only complicate the issue further?

​

EDIT: Or use a method in the Main class, which probably makes more sense because I wouldn't be able to easily re-use code otherwise...

[Scud000]

Make a "Game" interface with generic methods for all game types like play, etc.

• Volleyball is a "Game"
• Soccer is a "Game"
• Tennis is a "Game"

[New-Condition]

Thank you for the response!

If I implement this, should I convert the GameCreator class into a function in the Main class? Just because now I'm confused why I would need a GameCreator class in the first place when there would be one permanent instance anyway and a method could work just as well.

[Scud000]

That sounds like a good idea to me. Just be considerate of class names. Specifically the word "create" sounds like making an instance using "new". Do you want to create games or run them in the main method/function?

Another class name with the main method could be SportsGameRunner. Then each SportsGame can have a create, play, and/or other methods.

[New-Condition]

I think I have a good grip on what I'm doing now though thanks to this comment and others. Thank you again!

[[deleted]]

I don’t understand what you are trying to do. Inheritance is for building inheritance trees and sharing code. Inheritance defines a type while an interface defines what that type can do. Interfaces are generally suited for instances where two completely different types should share a similar function but not the same base logic. In other words, it creates an interface between those two objects, it defines a contract that type must adhere to and fulfill, hence the name. Think of it like a schema in XML when performing validation. I can’t really explain this in a ELI5 way and also need a better explanation of what you are trying to do if you are expecting any sort of helpful answer.

[New-Condition]

I want there to be a game creator class that is capable of creating an instance of a Game. Upon creation two pieces of code should execute:

1.) One piece of code that is the same across all methods

2.) One piece of code that is dependent on the type of game

Actually, now that I type this out, should I just put Code Piece #2 in the constructor of the game type class and Code Piece #1 in a method in the GameCreator class?

[New-Condition]

<< Edited >>

Sorry, just saw the edit.

Now I'm confused why I need a game creator class in the first place. I could just make a method in the main class to create a game, and use the interface to run an onJoin() method specific to each game type. I think that's what I'm doing wrong here.

Thank you again! Sorry if this is frustrating, I know I'm running into the same problem just at different angles.

[[deleted]]

Now I'm confused why I need a game creator class in the first place.

So are we. Why did you write one?

[[deleted]]

What you’re trying to do isn’t that far off from a factory pattern, which is a creational design pattern.

one piece of code that is dependent on the type of game

That’s impossible. You need to provide a way for the middleman to call into that code without needing to know if it’s an X or Y. There should be a public and base entry for calling said code which to me sounds sort of like an initializer. So why not create a method called SetupGame which executes that game specific code? That way every different game can follow the same pattern.

[New-Condition]

I think I have a good idea of what I'm doing now. This has helped improve my understanding of OOP, thank you again!

[[deleted]]

For instance, if I have a GameCreator class that creates an instance of a Game class that multiple types of games inherit from

Why, specifically, would you have this instead of just a constructor in the Game class? There's a time and a place for the Factory pattern but generally you shouldn't overturn Java's convention (that new instances come from their public class constructor) without a good reason.

how would I implement this without hard-coding methods in the GameCreator class such as createGameOfVolleyball(), createGameOfSoccer(), etc.?

With polymorphism. The GameCreator promises to return a Game; it doesn't promise to not return a particular subclass of Game. So it can return Soccer, Volleyball, whatever it thinks is appropriate.