# Is this an appropriate use of abstraction in my game engine?

I have been stuck in the design phase on my new game for a few weeks now because I keep finding new parts of the game engine that I could make more modular and neat. I did, however, run into a problem recently where I found that a seemingly logical modularization lead to some (what I thought to be) bad practices. Let me explain:

## The Situation

I am writing a game that has a series of physics objects, called Bead's that move around within the closed walls of the screen. Now, The Bead object contains all the necessary information that a Bead needs, however I recently removed the velocity and location information out and into a PhysicsObject class, as I figured if I ever wanted to introduce more shapes, I could reuse this code (a good practice, right?).

I then moved another part of the Bead out of the Bead class: the region bounding the drawn bitmap. This would allow me to create other regions in on the board that could react to touch input from the user (considering it is an Android game). I made this an interface (since you can only extend from one class at a time in Java), called Boundable, and had the Bead class inherit the traits from that class.

Note that one of the main reasons I pulled out this information because I wanted the Board object to also inherit these traits (because their bounding information is very similar) that would allow me to bound the screen and work with object collision in a much more object-oriented manner.

## The Problem

Since the interface contains information related to the bounds of an object, and since it must be an interface, then the access modifiers must be public either public, static or final, and I would prefer them to be protected. I don't want the location information of the objects in my game to be publicly available as it could permit some malicious program the ability to change the values. Am I correct in this assumption? Am I just going about this in the completely wrong way? Perhaps being too picky? Please let me know if you need any additional clarification.

Any help would be greatly appreciated.

Here is the code for those of you that would prefer to see what I'm doing first hand:

## Boundable.java

public interface Boundable{

//I would like these values to be protected.
public float left;
public float right;
public float top;
public float bottom;

public boolean contains(float x, float y){}
}


## UML Diagram

You may find a UML diagram of the setup I currently have, here.

In java those variables get converted to "public static final" variables, so it will not work as intended. You can only have the public access modifier in interfaces, you also do not need to explicitly write public as it is assumed.

// It is good practice to start interfaces with an I
public interface IBoundable
{
float getLeft();
float getRight();
float getTop();
float getBottom();

boolean contains(float x, float y) { }
}


Having your interface like this forces that implementer to have public get method, but they can hide the set method.

public class Bead implements IBoundable
{
private float left;

public float getLeft() { return left; }
protected float setLeft(float left) { this.left = left; }

...
}


Please also note that you can only extend from one class (like you said), but you can implement more than one interface.

• IIRC it's C# that starts interfaces with an I, and Java that doesn't. (At least in their standard libraries) – Robert Rouhani Dec 25 '12 at 8:29
• Ahh, yes this makes so much sense! I was simply using interfaces under the incorrect circumstances. The way you have phrased it makes it much more clear - only use interfaces when you want to enforce functionality..the underlying variables and the implementation of these methods should be left to the user. Thank you! – Squagem Dec 25 '12 at 15:58