Assigning value to Parameters

[Jackson Daniels]

Hello!

I have a few questions regarding parameters. Basically I am trying to get the distance between a point and "other". I believe that "other" will be given a value when the driver file is ran. However, I can not compile my file, because the variable xCoordinate (and yCoordinate) can not be found [symbol can not be found]. I am assuming it is the other. that is making the variable unfindable. Any suggestions on how to fix this would be greatly appreciated. Thank you.

    
public double distanceFrom(Point other){
      double xC = (xCoordinate - other.xCoordinate);
      double yC = (yCoordinate - other.yCoordinate);
      return Math.sqrt(xC*xC + yC*yC);
    }

[Maneesh Godbole]

Is point same as java.awt.Point?
If yes, then you should use point.x and point.y

[Jackson Daniels]

Not its not, basically all it is is:

public interface Point {

  double distanceFrom(Point other);
}

Im not really sure how to use interfaces, so any help is appreciated.

[Paweł Baczyński]

The variable other is of type Point. Point is an interface.
That means you can only invoke methods defined in the interface on other (plus all methods defined in Object class).

You can try adding getX() and getY() methods to the interface.

[Jackson Daniels]

So should I create a other class?

[Paweł Baczyński]

You should add methods I mentioned to the interface.

Please show us the code of the class implementing Point.

[Maneesh Godbole]

Think of interfaces as entities which define the capability (or offers a contract) of some functionality.

Consider a GraveDigger interface, who defines the capability (or offers a contract) to dig a grave.
You would write it as

	public interface GraveDigger{
		public void digGrave();
	}

As you can see, there is no mention of how the grave will be actually dug.

Now consider two businesses who offer to dig graves.
One is a bit short on capital, so they dig graves by shovels.
Another is an established business, so they use blackhoes.
You can represent them as

	public class NewBusiness implements GraveDigger{

		@Override
		public void digGrave() {
			new Shovel().dig();
		}
	}
	
	public class Established implements GraveDigger{

		@Override
		public void digGrave() {
			new BlackHoe().ignition();
		}
	}

As you can see, the end result is a freshly dug grave. However, the way the grave was dug, was different.
To summarize, an interface promises you some functionality. An implementation of that functionality can differ. From the outside, the consumer of the functionality is not aware (nor rarely cares) about the implementation.

[Jackson Daniels]

So should the implementation be done in the interface (say math equations) and then the outcome of those equations be returned in the class. For example:

//INTERFACE

public Interface Point{
   
    public double x;
    public double y;
    public distance (Point other){
        return Math.sqrt(x*x + y*y);
    }

//Public Class

public class Dist implements Point {
   
     //Somehow call distance from interface

}

[Paweł Baczyński]

No, you should not declare variables in interfaces.

Declare methods in the interface. Name them (for example) getX() and getY().

You can't provide implementations in interfaces (except for default methods introduced in Java 8).

What is Dist? Is dist(ance?) a point? I'd say it is not.

It looks to me that you don't need a Point to be interface at all. Just make it a class.

[Jackson Daniels]

Okay, so just.

public double getY();

[Liutauras Vilda]

Hi Jack,

Are you sure you're not doing it wrong way round? If it is an assignment, better give us some text from there (just to make sure you moving correct way).
I have a feeling that you should be writing concrete Point class and implementing Distance interface or very similar, but not other way round.

[Liutauras Vilda]

I think that should look something like (I could be wrong):

public class Point implements CalculatesDistance {
	private int x;
	private int y;
	
	public Point(int x, int y) {
		this.x = x;
		this.y = y;
	}
	
	public int getX() {
		return x;
	}
	
	public int getY() {
		return y;
	}
    
    /* Method to implement */
    @Override
    public double distance(Point other) {
        // code
    }
    
    @Override
	public String toString() {
		return "(" + x + "," + y + ")";
	}
}

and interface:

public interface CalculatesDistance {
    double distance(Point other);
}

Let's see what more experienced guys think.

[Maneesh Godbole]

IMO the OP needs to share some more information on why he wants an interface. Based on the discussion till now I do not see any need.
Point represents co-ordinates. Concrete implementation is the correct way.
Distance calculations can either be done by
1) The point instance can calculate the distance between it and another point
2) Have a helper class which will do it.

[Winston Gutkowski]

Maneesh Godbole wrote:IMO the OP needs to share some more information on why he wants an interface. Based on the discussion till now I do not see any need.

I'm not sure I agree (about the second bit).

One advantage of making Point an interface is that it can then be implemented in more than one way (eg, mutable/immutable) or by a class that shares its characteristics, eg:

public final class Pixel
   implements Point, Coloured
{ ...

Jack Daniels wrote:So should the implementation be done in the interface...

No. Interfaces - at least before version 8 - are about defining the behaviour of a type - ie, what methods it provides.

But it should be complete. Presumably distance() isn't the only thing a Point can do, so you need to think about exactly what you do want it to do.

There's also absolutely nothing wrong with doing both - writing an interface and a class - and it has many advantages.

For example: does everyone who uses a Point object need to know what its 'x' and 'y' values are? Maybe in some cases, but certainly not in all.

So you could write something like:

public abstract class AbstractPoint
   implements Point
{
   private int x;
   private int y;

   public AbstractPoint(int x, int y) {
      this.x = x;
      this.y = y;
   }

   protected final int x() {
      return x;
   }

   protected final int y() {
      return y;
   }

   @Override
   public final double distance(Point other) {
      // code
   }
   ...
}

which provides "getter" methods for designers, but not for the coderanch.

BTW, the above is called a "skeleton implementation", and you'll find it a lot in the Java Collections Framework. Have a look at AbstractList (←click→) and AbstractMap.

Hope it's not too much information for you.

Winston

[Fred Kleinschmidt]

You shouldn't call your interface "Point" since it will conflict with Java's Point class. And consider using Java's Point2D.Double class (instead of writing your own class and/or interface ), as it already has a distance() method, among others.

[Winston Gutkowski]

Fred Kleinschmidt wrote:You shouldn't call your interface "Point" since it will conflict with Java's Point class. And consider using Java's Point2D.Double class (instead of writing your own class and/or interface ), as it already has a distance() method, among others.

Not sure I agree with either of those points (no pun intended), but the fact that Java already has a Point class is definitely worth knowing; so have a cow.

My problem with Point2D.Double (and actually with most Java "Point" implementations) is that it's mutable, when there's really no reason for it to be.

But that's probably just my prejudice.

Winston

[Fred Kleinschmidt]

My problem with Point2D.Double (and actually with most Java "Point" implementations) is that it's mutable

I agree here. When I want an immutable one, I create my own class with a private Point2D.Double variable, and pass everything along to that. For example,

public class MyPoint {
  private Point2D.Double p;
  public MyPoint( double x, double y ) {
    p = new Point2D.Double(x,y);
  }
  public double distance( MyPoint m ) {
    return p.distance(m.p);
  }
  public double getX() {
    return p.x;
  }
// etc.
}