Почему Платформа Наборов Java предлагает два различных способа отсортировать?
Если бы у меня есть список элементов, я хотел бы отсортировать, Java предлагает два способа пойти об этом.
Например, позволяет, говорят, что у меня есть список Объектов видеоклипа, и я хотел бы отсортировать их по заголовку.
Одним путем я мог сделать, это путем вызова версии с одним аргументом статического java.util. Collections.sort () метод с моим списком видео как отдельный аргумент. Таким образом, я назвал бы Collections.sort(myMovieList). Для этого для работы класс Фильма, как должны были бы объявлять, реализовал бы java.lang. Сопоставимый интерфейс и требуемый метод compareTo () должны были бы быть реализованы в этом классе.
Другой способ отсортировать путем вызова версии с двумя аргументами статического java.util. Collections.sort () метод со списком видео и java.util. Объект компаратора, поскольку это - аргументы. Я назвал бы Collections.sort (myMovieList, titleComparator). В этом случае класс Фильма не реализовал бы интерфейс Comparable. Вместо этого в основном классе, который создает и поддерживает сам список видео, я создал бы внутренний класс, который реализует java.util. Интерфейс Comparator и реализация один требуемый метод выдерживают сравнение (). Затем я создал бы экземпляр этого класса и назвал бы версию с двумя аргументами вида (). Преимущество этого второго метода - Вы, может создать неограниченное количество эти внутренний класс Компараторы, таким образом, можно отсортировать список объектов по-разному. В примере выше, у Вас мог быть другой Компаратор к виду к году, которым фильм был сделан, например.
Мой вопрос, почему беспокойство для изучения обоих способов отсортировать в Java, когда версия с двумя аргументами Collections.sort () делает все первая версия с одним аргументом, делает, но с дополнительным преимуществом способности отсортировать элементы списка на основе нескольких различных критериев? Это было бы то меньше вещи должным быть оставаться в Вашем уме при кодировании. У Вас был бы один основной механизм сортировки списков в Java для знания.
3 ответа
Один предназначен для краткости того, что должно быть обычным случаем ( Эффективное второе издание Java, пункт 12: подумайте о реализации Comparable ). Другой, как вы отметили, предназначен для гибкости и универсальности.
Связанные вопросы
Это зависит от того, кто контролирует упорядочивание. Если упорядочивание объекта является деталью реализации объекта, то Comparable является более подходящим. Если упорядочивание объектов контролируется вызывающей стороной, то больше подходит Comparator.
Я не уверен, что нахожу это настолько странным. У меня есть список вещей для сортировки, которые имеют естественный порядок, как числа. Неужели я действительно ожидаю, что мне придется указывать API, как сравнивать числа? Интуитивно я бы не стал искать метод с двумя аргументами. Таким образом, Comparable существует.
Но, конечно, вы можете и должны быть в состоянии определить другое упорядочивание, таким образом, другой метод. Например, даже если числа имеют естественный порядок, я все равно могу захотеть другой порядок: например, упорядочить по убыванию значения. Таким образом, существует Comparator.
И, конечно, некоторые вещи не имеют естественного упорядочения, как, например, Fruit, но вы все равно можете захотеть упорядочить их список. Таким образом, Comparator снова существует.