2014-02-18 2 views
0

Должен ли я всегда придерживаться договора, установленного для Comparable Interface? Существует ли приемлемое плечо, когда все три случая контракта неясны?Java Сопоставимый контракт

Контракт просто заявляет:

If this object precedes that; return negative value 
If this object equals that; return zero 
If this object proceeds that; return positive value 

Я хочу, чтобы сравнить две точки, которые Point2D объекты. Сравнение двух точек с использованием поведения distance(Point2D point) приводит к появлению двоичного кода compareTo(); Либо две точки имеют нулевое расстояние, либо их расстояние отличное от нуля.

Если бы я написать такую ​​compareTo() поведение, которое перекрывает по умолчанию, возможно, это будет выглядеть следующим образом:

private Point2D location; 

public int compareTo(Object o) 
{ 
    if(this.getLocation().distance(o.getLocation() == 0) 
    { 
     return 0; 
    } 
    else 
    { 
     return 1; 
    } 
} 

Возможно, сравнивающие два объекта Point2D бы лучше подходит, используя простое расстояние тестирования поведения и не заморачиваться реализации Comparable. Возможно, даже есть способ присоединиться к контракту, которого я не знаю.

+0

Это зависит от вас, чтобы определить, что означает «предшествует», «равно» и «продолжается» означает в вашем контексте. До тех пор, пока вы поддерживаете правило, что если a> b и b> c, a> c и эквивалент с <и =. –

+0

(И должно быть верно, что если a> b, то b

+0

Например, вы можете заказать, исходя из расстояния от источника или какой-либо другой контрольной точки. –

ответ

3

Всегда строго придерживайтесь договора интерфейса, который вы реализуете, особенно такого, как Comparable, который определен в основном API. Если вы не можете определить всего порядка на свой тип, чтобы сравнение двух объектов всегда было стабильным и что переходное сравнение всегда стабильно, ваш класс будет приводить к ошибкам выполнения в коде, который может быть удален из вашего класса, особенно если ваши объекты добавлены к Set.

Ваш прецедент действительно звучит не так, как будто вы описываете порядок элементов, а скорее какой-то equals; Comparable/Comparator, кажется, неправильный подход полностью.

6

Похоже, что реализация Comparable не имеет смысла для этого варианта использования. С другой стороны, одним из возможных вариантов этого подхода будет Comparator<Point2D> closestTo(Point2D point), который сравнивает две точки A и B, которые ближе к третьей точке C.

Метод, который вы описываете, по существу, должен быть equals метод - в этом случае вы должны просто переопределить equals с таким поведением. Нет никакого смысла в этом сравнивать.

Смежные вопросы