Ответ 1
Интерфейс java.util.List
не поддерживает getLast()
, потому что дизайнеры пошли на "минимальный интерфейс". С минимальным количеством методов, которые он определяет, он упрощает понимание и ускорение обучения.
Это контрастирует с "гуманным интерфейсом" (например, используется в классе массива Ruby), который пытается предоставить методы для выполнения общих операций (например, getLast()
). Поскольку существует много применений, которые могут быть связаны с такой фундаментальной концепцией, как список, это приводит к значительно большим интерфейсам.
Для получения дополнительной информации см. Martin Fowler Минимальный интерфейс и Гуманный интерфейс описания.
Что касается того, почему LinkedList поддерживает getLast()
и т.д., чтобы процитировать javadoc:
... класс LinkedList предоставляет равномерно названные методы для получения, удаления и вставки элемента в начале и конце списка. Эти операции позволяют связанным спискам использоваться в качестве стека, очереди или очереди с двойным завершением (deque).
Предположительно было высказано мнение, что общий список не будет адекватным для этих конкретных случаев использования.
Как понимание ума главного дизайнера API Java Collections (Joshua Bloch), он предоставляет этот список шаблонов дизайна API который он работает. Из них наиболее уместными в этом вопросе являются:
Ранние проекты API должны быть короткими, как правило, одной страницей с подписями классов и методов и однострочными описаниями. Это упрощает реструктуризацию API, когда вы не получите его в первый раз.
Если у вас есть сомнения, оставьте это. Если есть фундаментальная теорема проектирования API, то это он. Он в равной степени относится к функциональности, классам, методам и параметрам. Каждый аспект API должен быть как можно меньше, но не меньше. Вы всегда можете добавить вещи позже, но вы не можете их отнять. Минимизация концептуального веса важнее, чем оценка класса или метода.
Храните API без сведений о реализации. Они путают пользователей и препятствуют развитию гибкости. Не всегда очевидно, какая деталь реализации: Будьте осторожны с превышением.
Минимизировать доступность; когда вы сомневаетесь, сделайте это частным. Это упрощает API и уменьшает сцепление.
Рассмотрим последствия производительности решений по проектированию API, но не деформируйте API для достижения повышения производительности. К счастью, хорошие API обычно поддаются быстрым реализациям.
Однако он также заявляет:
Не заставляйте клиента делать что-либо, что может сделать библиотека. Нарушение этого правила приводит к заключению шаблона в клиенте, что является раздражающим и подверженным ошибкам.
Что только показывает, что рекомендации по дизайну часто конфликтуют, а самая трудная часть работы дизайнеров API - это сбалансировать эти конфликты.