Наследование, композиция и методы по умолчанию

Я не очень понимаю здесь большую проблему. Вы по-прежнему можете поддерживать свой UserDatabase с помощью ArrayList, даже если не расширяете его, и получить производительность за счет делегирования. Вам не нужно расширять его, чтобы получить производительность.

public class UserDatabase implements List<User>{
   private ArrayList<User> list = new ArrayList<User>();

   // implementation ...

   // delegate
   public Spliterator() spliterator() { return list.spliterator(); }
}

Ваши два пункта не меняют этого. Если вы знаете, что «у ArrayList есть собственная, более эффективная реализация spliterator()», вы можете делегировать ее своему вспомогательному экземпляру, а если вы не знаете, то об этом позаботится метод по умолчанию.

Я до сих пор не уверен, имеет ли смысл реализовывать интерфейс List, если только вы явно не создаете повторно используемую библиотеку Collection. Лучше создайте свой собственный API для таких одноразовых проектов, который не приведет к будущим проблемам через цепочку наследования (или интерфейса).

Я не могу дать совет для каждой ситуации, но для этого конкретного случая я бы предложил вообще не реализовывать List. Какова будет цель UserDatabase.set(int, User)? Вы действительно хотите заменить i-ю запись в резервной базе данных совершенно новым пользователем? А add(int, User)? Мне кажется, что вы должны либо реализовать его как список только для чтения (выбрасывая UnsupportedOperationException при каждом запросе модификации), либо поддерживать только некоторые методы модификации (например, add(User) поддерживается, а add(int, User) — нет). Но последний случай сбил бы пользователей с толку. Лучше предоставить свой собственный API модификации, который больше подходит для вашей задачи. Что касается запросов на чтение, наверное, было бы лучше возвращать поток пользователей:

Я бы предложил создать метод, который возвращает Stream:

public class UserDatabase {
    List<User> list = new ArrayList<>();

    public Stream<User> users() {
        return list.stream();
    }
}

Обратите внимание, что в этом случае вы можете полностью изменить реализацию в будущем. Например, замените ArrayList на TreeSet или ConcurrentLinkedDeque или что-то еще.

Выбор прост в зависимости от ваших требований.

Примечание. Ниже приведен пример использования. чтобы проиллюстрировать разницу.

Если вам нужен список, в котором не будет дубликатов и который будет делать целую кучу вещей, сильно отличающихся от ArrayList, тогда нет смысла расширять ArrayList, потому что вы пишете все с нуля.

В приведенном выше вы должны Implement List. Но если вы просто оптимизируете реализацию ArrayList, вам следует скопировать и вставить всю реализацию ArrayList и следовать оптимизации вместо extending ArrayList. Почему, потому что многоуровневая реализация мешает кому-то разобраться.

Например: компьютер с 4 ГБ оперативной памяти в качестве родителя и ребенка имеет 8 ГБ оперативной памяти. Плохо, если у родителя 4 ГБ, а у нового ребенка 4 ГБ, чтобы получилось 8 ГБ. Вместо детской реализации с 8 Гб ОЗУ.

Я бы предложил composition в этом случае. Но он будет меняться в зависимости от сценария.

Обычно признается, что расширение реализации интерфейса посредством наследования не является лучшей практикой, и что композиция (например, повторная реализация интерфейса с нуля) более удобна в сопровождении.

Я вообще не думаю, что это точно. Конечно, есть много ситуаций, когда композиция предпочтительнее наследования, но есть много ситуаций, когда наследование предпочтительнее композиции!

Особенно важно понимать, что структура наследования ваших классов реализации не обязательно должна быть похожа на структуру наследования вашего API.

Кто-нибудь действительно верит, например, что при написании графической библиотеки, такой как Java swing, каждый класс реализации должен переопределять метод paintComponent()? На самом деле весь принцип дизайна заключается в том, что при написании методов рисования для новых классов вы можете вызывать super.paint() и это гарантирует, что все элементы в иерархии будут отрисованы, а также дальнейшее решение сложностей, связанных с взаимодействием с собственным интерфейсом. вверх по дереву.

Общепризнано, что расширение классов, не находящихся под вашим контролем, которые не предназначены для поддержки наследования, опасно и потенциально может стать источником раздражающих ошибок при изменении реализации. (Поэтому отметьте свои классы как окончательные, если вы оставляете за собой право изменить свою реализацию!). Я сомневаюсь, что Oracle внесет критические изменения в реализацию ArrayList! Если вы уважаете его документацию, вы должны быть в порядке....

В этом изящество дизайна. Если они решат, что есть проблема с ArrayList, они напишут новый класс реализации, подобно тому, как когда-то заменили Vector, и не будет необходимости вносить критические изменения.

===============

В вашем текущем примере оперативный вопрос: почему этот класс вообще существует?

Если вы пишете класс, который расширяет интерфейс списка, какие другие методы он реализует? Если он не реализует новых методов, что плохого в использовании ArrayList?

Когда вы знаете ответ, вы будете знать, что делать. Если ответ «Мне нужен объект, который в основном представляет собой список, но имеет некоторые дополнительные удобные методы для работы с этим списком», тогда я должен использовать композицию.

Если ответ «Я хочу коренным образом изменить функциональность списка», вам следует использовать наследование или реализовать его с нуля. Примером может быть реализация неизменяемого списка путем переопределения метода добавления ArrayList для создания исключения. Если вам не нравится этот подход, вы можете подумать о реализации с нуля, расширив AbstractList, который существует именно для того, чтобы наследоваться, чтобы свести к минимуму усилия по повторной реализации.