Is passing object itself (this) to a field's method a bad approach?

Question

I'm programming a small game and I have two classes: Board and Piece. Board have (so far) one Piece which can be moved in borders of Board.

public class Board {
  private Piece piece_;
  private int width, height;
  ...

  movePieceDown() {
    piece_.moveTo(this, 1, 2);
  }
}

public class Piece {
  public boolean moveTo(Board board, int x, int y) {
    // move piece to new location (x,y)
    // return true if successful
  }
}

Is it bad approach if I in piece_.moveTo(this, 1, 2); pass reference to Board so Piece could move to new location if there is no obstacles on Board? Without passing reference to Board, Piece doesn't know if there is obstacles on new location or is it out of Board borders.

It is in my opinion that every object should worry only about self: Piece should move to new location and Board should worry if it is legal move or not, BUT this sample code I have posted makes more sense and simplifies things.

TL;DR: Am I breaking some OOP guideline with passing object itself to a field's method or is it some normal OOP idiom? Thank you in advance for clarifying this to me.

Answer 1

It's not a bad approach. Passing this to various methods is not uncommon thing in programming. It just depends on your design and as far as I'm concerned, nothing in Piece class.

One thing in the Board class might be confusing - movePieceDown method. You have unusable parameter Board board. If you are planning to use this as an argument, remove that attribute because the board should not receive other boards as potential arguments, and as a matter of fact, should not be aware that other boards can exist.

And finally, you could make sure that Piece sees an interface of the Board as a method parameter, and make sure that that contract will never change. For example, it could have these methods:

public interface IBoard { 
    public boolean isFieldFree(int x, int y)
    public Piece getPiece(int x, int y) 
}

No matter how you change implementation of the Board later, this is something that should always work so you don't have to rework your Piece code when you change the Board. This way you could enforce a rule that a Piece cannot change the state of your board (in the interface, don't expose any methods that change the state of the board).