Является ли реализация Iterator для конкретной коллекции в java примером шаблона проектирования адаптера? - PullRequest
2 голосов
/ 13 апреля 2019

Является ли реализация Iterator для конкретной коллекции примером шаблона проектирования адаптера?

Например: - Итераторная реализация ArrayList оборачивает адаптер ArrayList, а итераторная реализация HashSet оборачивает HashSet adaptee.

Ответы [ 3 ]

1 голос
/ 13 апреля 2019

Интересная перспектива!

Как правило, шаблоны Adapter и Iterator пытаются решить различные проблемы.Прежний используется для того, чтобы существующие несовместимые сущности (классы) работали друг с другом без их изменения, тогда как
последний помогает в последовательном доступе к элементам некоторой агрегированной сущности (Список или Коллекция) без необходимости понимать основную логику.

Возвращаясь к вашему вопросу,

Является ли реализация Iterator для определенной коллекции примером шаблона проектирования адаптера?

Не совсем.

Потребность в шаблоне адаптера возникает, когда уже существует два несовместимых класса, и вы пытаетесь ввести адаптер, чтобы сделать возможной связь между двумя классами.Но в случае шаблона Iterator у нас уже определен интерфейс Iterator.Так что все наоборот.Любой новый класс, желающий взаимодействовать с итератором Collection, должен определить себя таким образом, чтобы он мог понимать интерфейс итератора.Кроме того, iterator ограничивает функциональность доступом к элементам базовой коллекции, тогда как Adapter обеспечивает связь между двумя классами.

Надеюсь, это ответит на ваш вопрос.

0 голосов
/ 14 апреля 2019

Нет, потому что все реализации коллекции в Java должны расширять интерфейс java.util.Collection, который имеет метод iterator .И нет необходимости создавать адаптер для коллекции, чтобы получить для него итератор.

Но нам нужно создать адаптер для других классов, которые не реализуют java.util.Collection или java.lang.Iterable.Например, для хорошо известного org.apache.commons.lang3.tuple.Pair класса.Ниже приведен пример того, как создать адаптер, который позволяет перебирать свойства, например, над коллекцией:

import org.apache.commons.lang3.tuple.ImmutablePair;
import org.apache.commons.lang3.tuple.Pair;

import java.util.Iterator;

public class DesignPatterns {

    public static void main(String[] args) {
        Pair<String, String> pair = new ImmutablePair("A", "B");
        for (String item : new PairIterableAdapter<>(pair)) {
            System.out.println(item);
        }
    }
}

class PairIterableAdapter<T> implements Iterable<T> {

    private final Pair<T, T> pair;

    public PairIterableAdapter(Pair<T, T> pair) {
        this.pair = pair;
    }

    @Override
    public Iterator<T> iterator() {
        return new Iterator<>() {
            private int counter = 2;

            @Override
            public boolean hasNext() {
                return counter-- > 0;
            }

            @Override
            public T next() {
                switch (counter) {
                    case 1:
                        return pair.getLeft();
                    case 0:
                        return pair.getRight();
                    default:
                        throw new IndexOutOfBoundsException("No more elements!");
                }
            }
        };
    }
}

Надпечатки кода выше:

A
B

Для коллекций нам не нужно это делать, потому чтов их реализации уже есть метод iterator().

См. также:

0 голосов
/ 14 апреля 2019

Нет, оба шаблона полагаются на интерфейсы и инкапсуляцию , в частности скрытие информации , но, как указывают Girish и user207421, у них разные проблемы:

  • Шаблон адаптера разрешает различные интерфейсы, используя интерфейсы и скрывая информацию
  • Шаблон Iterator предоставляет согласованный интерфейс для итерации произвольных структур, также опираясь на интерфейсы и сокрытие информации

Большинство шаблонов используют одну или несколько основ ООП, поэтому, скорее всего, вы их перепутаете / обнаруживаете перекрытие, но их проблемы отличают их.

...