IIUC I should decouple UI logic from the model and controller in my project. I didn't succeed and had to resort to TextView etc in my game logic:

package dev.game.adventure;

import android.graphics.drawable.Drawable;
import android.widget.TextView;

public class Adventure {

    private Player player;

    public Player getPlayer() {
        return player;

    public Adventure(TextView t, AdventureActivity target, PlaceView placeView) {
        World world = new AdventureWorld(this, t, target, placeView);
        Person me = new Person(world, "You", 0, target);
        placeView.mainCharacter = me;
        player = new Player(world, me, t);

    public Drawable loadPicture(int imageName, AdventureActivity target) {
        Drawable im = target.getResources().getDrawable(imageName);
        return im;

I have similar to the above in several classes, passing on an android activity and/or a textview into model and controller objects. Will this be a problem and is it possible to solve?


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.


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.

| improve this answer | |

Extract an interface

Ask yourself the question: "Why do I need to pass this TextView?"

I took a look at your code for the AdventureWorld class, and there you are not using it at all. So why are you passing it?

I also took a look at your code for the Player class, and you are not using it there either!

So, let's say that you would use it, let's say that your code needs to append some text to this TextView. We can do that by passing something else than a TextView. Let's pass it some callback. As I don't know what you're planning to use it for, I'm gonna call it MessageCallback

public interface MessageCallback {
    void message(String text);

Now you can pass a MessageCallback instead of a TextView, making the constructor something like:

public Adventure(MessageCallback t, AdventureActivity target, PlaceView placeView) {

And creating it:

MessageCallback callback = new MessageCallback() {
    @Override public void message(String text) {
        // here you have access to the TextView from the activity, so use it.
... = new Adventure(callback, activity, placeView);

Note however that you should do the same thing with your AdventureActivity and your PlaceView as well. Find out why you need to pass them and instead pass a callback interface.

General advice

Let your view-classes know about your model, but do not pass the view-classes to your model. Use callback interfaces and pass to your view to decouple your view from your model.

Using this approach with all your view classes, you should be able to build a pure console application game as your "view" as well as an Android application.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.