Decoupling UI code from game logic
OOP doesn't mean to "split up" code into random classes.

The ultimate goal of OOP is to reduce code duplication, improve readability and support reuse as well as extending the code.

Doing OOP means that you follow certain principles which are (among others):


information hiding / encapsulation
single responsibility
separation of concerns
KISS (Keep it simple (and) stupid.)
DRY (Don't repeat yourself.)
"Tell! Don't ask."
Law of demeter ("Don't talk to strangers!")
replace branching with polymorphism


You example suffers multiple violations of this OO principles.

e.g:

Single Responsibility / Separation of concerns.

The (only) method in you class does nothing but delegates the call to one of it's parameters while passing the other parameter. This is the reverse version of feature envy. This method has no reason to exist here. 

And since this is the only method in this class (you showed) the whole class has no reason to exist.

interface segregation

Your constructor has 3 parameters but  there is only one member variable initialized.  

The complete content should be outside the constructor and only the Player instance should be passed in to be assigned to the member variable.