Принудительный клиент для обеспечения реализации внутреннего класса при расширении внешнего класса

Question

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

Чтобы объяснить ситуацию лучше: Я абстрактный класс

public abstract class ImmutablePolynomial implements Iterable { 

    protected int degree; 

    static ImmutablePolynomial sum(ImmutablePolynomial x, ImmutablePolynomial y) { 
     .... Some Implementation using an iterator over terms and a return statement.... 
    } 

    public abstract TermIterator iterator(); 

    Here I want an innerclass (TermIterator) extending Iterator that must be implemented 
    if you extend ImmutablePolynomial. 

Теперь клиент может обеспечить реализацию в ImmutablePolynomial, используя специфические для структуры данных, например, уменьшить использование памяти, расширяя этот класс. Как заставить клиента также обеспечить реализацию Interclass Implementing Iterator, чтобы сумма статического метода в ImmutablePolynomial также работала с реализацией, предоставляемой клиентом?

Также, если это плохая идея/антипаттерн/есть лучшая альтернатива, скажите мне об этом. Я делаю это, чтобы улучшить свое кодирование.

Edit 1: удалить поле

защищенных термины Коллекции

, как в посоветовал комментарии. Edit 2: сделать метод

итератор()

аннотация как посоветовали в комментариях

Answer 1

Учитывая, что ImmutablePolynomial класс является абстрактным, так что вы никогда не будете иметь объект, класс это ImmutablePolynomial, и вам не нужны экземпляры подклассов ImmutablePolynomial для использования класса ImmutablePolynomial.TermIterator, когда будет ImmutablePolynomial.TermIteratorкогда-либо? Бессмысленно реализовывать его как внутренний класс.

Как @Tassos в комментариях, объявите TermIterator как интерфейс; это может быть вложен в класс ImmutablePolynomial или нет, как вы предпочитаете. Также сделайте реферат ImmutablePolynomial.iterator().

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