Interface question
I have the following interface..publicinterface ChessPiece
{
/**
a method that determines if a chess piece can move the
specified displacement.
@param hthe horizontal displacement
@param vthe vertical displacement
@returntrue or false
*/
boolean canMove(int h,int v);
/**
a method that determines if a chess piece can capture
in the specified displacement
@param hthe horizontal displacement
@param vthe vertical displacement
@returntrue or false
*/
boolean canTake(int h,int v);
/**
a method that returns what Color the chess piece is.
@returna Color object containing the color of the piece.
*/
ChessPieceColor getColor();
/**
a method that tells a chess piece to more (or lets it know
that it has moved)
*/
void move();
}
Is it possible for me to add in a couple of fields into the interface? Such that if some class is going to implement this interface, they must have variable int x as part of the class..
From what I've read so far, it's not possible to specify fields in an interface - but I thought I'd ask anyway to make sure. How about constructors? Could I, for example, have my interface require the implementing class to meet some constructor requirement?publicinterface ChessPiece
{
int x;// never possible at all?
ChessPiece(int x,int y);// possible to demand a constructor type?
}
[2279 byte] By [
JJCoolBa] at [2007-11-27 3:44:22]
> Is it possible for me to add in a couple of fields into the interface?
No, the only fields an interface can have are public final static -- what some
might be tempted to call "constants".
> How about constructors?
No.
> Could I, for example, have my interface require the implementing class to meet some constructor requirement?
No.
So in this case if I wanted to accomplish what I posted above, I'd need to define a ChessPiece class instead of an interface, and then extend it instead of implement it?
Often this pattern emerges (using your example):
interface ChessPiece {
...
}
abstract class AbstractChessPiece implements ChessPiece {
//some fields
protected AbstractChessPiece (...) {...} //one or more constructors
//some boilerplate code, some interface methods given default implementations...
}
Then various concrete classes either extend AbstractChessPiece or directly implement ChessPiece.
Ahhhh. I see. That's a good design tip. Thanks! I'll give ya da dukes, Dr. (once I add 'em to the thread) ^.^ We'll go with 4 for this one.
so ... just for a more simple example. Would this be correct?
interface ChessPiece
{
boolean canMove(int h, int v);
}
abstract class AbstractChessPiece implements ChessPiece
{
int x, y;
AbstractChessPiece(int x, int y)
{
this.x = x;
this.y = y;
}
protected boolean canMove(int h, int v)
{
// generic piece code goes here
}
}
class Knight extends AbstractChessPiece
{
Knight(int x, int y)
{
super(x,y);
}
public boolean canMove(int h, int v)
{
// Knight specific code goes here
}
}
> so ... just for a more simple example. Would this be
> correct?
> interface ChessPiece
> {
>boolean canMove(int h, int v);
>
>
> abstract class AbstractChessPiece implements
> ChessPiece
> {
>int x, y;
>AbstractChessPiece(int x, int y)
> {
>this.x = x;
> this.y = y;
>}
>protected boolean canMove(int h, int v)
> {
>// generic piece code goes here
>
> }
>
> class Knight extends AbstractChessPiece
> {
>Knight(int x, int y)
> {
>super(x,y);
>
>
>public boolean canMove(int h, int v)
> {
>// Knight specific code goes here
>
> }
Yep, that would be a typical way to do this. Apart from the fact that you can't reduce the visibility of an overriden or implemented method, so canMove has to stay public. Indeed, you wouldn't want to reduce it. If canMove is something you feel is only for use internally by the class itself, it doesn't belong on the interface (I think it does)
Looks good, although I wonder if there really is generic code for canMove. If, not, do nothing and leave it abstract in AbstractChessPiece.
probably not.. In my head, the generic implementation would simply bereturn false;
but in this situation, nothing at all would be better so that the extending piece would be forced to define it's own specific method. Anyway -- thanks again Dr. ^.^
> but in this situation, nothing at all would be better so that the extending piece would be forced to define it's own specific methodExactly
> Yep, that would be a typical way to do this. Apart
> from the fact that you can't reduce the visibility of
> an overriden or implemented method, so canMove has to
> stay public. Indeed, you wouldn't want to
> reduce it. If canMove is something you feel is only
> for use internally by the class itself, it doesn't
> belong on the interface (I think it does)
Not sure how I missed your post, George. But yes, the canMove() is definately needed as a public method. Mistake on my part. The "can't reduce visibility" I wasn't aware of, though, so that's good to know.
