Почему интерфейс Java List не поддерживает getLast ()?
Я знаю, что прошло много времени с тех пор, как был задан вопрос, но я нашел простое решение и подумал, что кто-то может его использовать (извините за плохой английский). Вот оно:
CSS
.main, .sidebar {
float: none;
padding: 20px;
vertical-align: top;
}
.container {
display: table;
}
.main {
width: 400px;
background-color: LightSlateGrey;
display: table-cell;
}
.sidebar {
width: 200px;
display: table-cell;
background-color: Tomato;
}
HTML
<div class="container clearfix">
<div class="sidebar">
simple text here
</div>
<div class="main">
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam congue, tortor in mattis mattis, arcu erat pharetra orci, at vestibulum lorem ante a felis. Integer sit amet est ac elit vulputate lobortis. Vestibulum in ipsum nulla. Aenean erat elit, lacinia sit amet adipiscing quis, aliquet at erat. Vivamus massa sem, cursus vel semper non, dictum vitae mi. Donec sed bibendum ante.
</div>
</div>
Простой пример. Обратите внимание, что вы можете превратиться в отзывчивость.
7 ответов
Интерфейс java.util.List не поддерживает getLast () , потому что дизайнеры выбрали «минимальный интерфейс». Благодаря минимальному количеству определенных методов он упрощает понимание и ускоряет обучение.
Это контрастирует с «гуманным интерфейсом» (например, используемым в классе массива Ruby ), который пытается чтобы предоставить методы для выполнения общих операций (например, getLast () ). Поскольку существует множество применений, к которым может быть добавлено такое фундаментальное понятие, как список, это приводит к созданию гораздо более крупных интерфейсов.
Для получения дополнительной информации см. Мартин Фаулер Минимальный интерфейс и Humane Interface .
Относительно того, почему LinkedList поддерживает getLast () и т. Д., Процитируем javadoc:
... класс LinkedList предоставляет методы с одинаковыми именами для получения, удаления и вставки элемента в начало и конец списка. Эти операции позволяют использовать связанные списки в качестве стека, очереди или двусторонней очереди (deque).
По-видимому, считалось, что общий список не подходит для этих конкретных случаев использования.
В качестве понимания в сознание главного разработчика Java Collections API (Джошуа Блох) он предоставляет этот список принципов проектирования API , по которым он работает. Из них наиболее актуальными для этого вопроса являются:
Ранние проекты API должны быть короткими, обычно одна страница с сигнатурами классов и методов и однострочными описаниями. Это упрощает реструктуризацию API, если вы не понимаете его с первого раза.
Если есть сомнения, оставьте это. Если есть фундаментальная теорема проектирования API, то это она. Это в равной степени применимо к функциям, классам, методам и параметрам. Каждый аспект API должен быть как можно меньше, но не меньше. Вы всегда можете добавить вещи позже, но вы не можете их убрать. Минимизация концептуального веса более важна, чем количество классов или методов.
Не допускайте наличия деталей реализации в API. Они сбивают с толку пользователей и препятствуют развитию гибкости. Не всегда очевидно, что является деталью реализации: остерегайтесь чрезмерной спецификации.
Минимизируйте доступность; в случае сомнений сделайте это приватным. Это упрощает API-интерфейсы и снижает взаимосвязь.
Учитывайте последствия для производительности проектных решений API, но не искажайте API для достижения прироста производительности. К счастью, хорошие API-интерфейсы обычно поддаются быстрой реализации.
Однако он также заявляет:
Не заставляйте клиента делать то, что могла бы сделать библиотека. Нарушение этого правила приводит к появлению шаблонного кода в клиенте, который раздражает и подвержен ошибкам.
Это просто показывает, что рекомендации по проектированию часто противоречат друг другу, и самая сложная часть работы разработчиков API - уравновесить эти конфликты.
Обычно причина в том, что они хотели указать каждую функцию с требованием Big-O и считали, что getLast () не может быть эффективно реализована во всех списках. Поэтому они вводят его на каждом уровне с обещанием Big-O.
Или это могло быть просто оплошностью, или они чувствовали, что это недостаточно распространено, и если вам это нужно, вы можете получить это с помощью size / getIndex.
Как вы сказали, с помощью List вы можете получить последний с помощью getIndex (), поскольку он основан на индексе. Так что лично я не вижу веских причин для его использования (поскольку вы можете написать его самостоятельно).
Хотя LinkedList не основан на массивах, поэтому нет индексов, имеет смысл предоставить такой метод, иногда вам нужно знаю последний элемент.
Цель интерфейса - обеспечить максимальное удобство использования с наименьшим возможным количеством общедоступных методов. Чем меньше методов поддержки, тем лучше. Нет метода getLast (), потому что он может быть получен, как вы сказали.
LinkedList, с другой стороны, представляет собой конкретную реализацию и, следовательно, не имеет этих проблем.
Изменить: как указал Скаффман, это не основная цель интерфейса. Это скорее второстепенная цель, которая упрощает поддержку реализации этого интерфейса. Основная цель интерфейса - отделить конкретную реализацию от объектов, которые ее используют.
Метод getLast () взят из интерфейса Deque, который реализует LinkedList. Если вам нужна версия с поддержкой массива, вы можете использовать ArrayDeque. Я предполагаю, что это не часть интерфейса List, потому что они хотели разделить различные абстрактные типы данных на отдельные интерфейсы, хотя такая реализация, как LinkedList, может реализовывать более одного интерфейса.
getLast () не может быть реализован в одностороннем связанном списке. getIndex () в одностороннем связанном списке, вероятно, просканирует весь список с самого начала, поэтому это влияет на эффективность.
Интерфейс List не имеет никаких вспомогательных методов этого типа. Нет getFirst () или getLast (). Он строго основан на индексах. LinkedList нужен способ избежать поиска на основе индекса, если это возможно из соображений производительности, поэтому getLast на самом деле является оптимизацией, а не удобным методом.
Я уверен, что дизайнеры хотели сократить количество методов, поэтому они этого не сделали. добавить много потенциально удобных методов.