Force Client, um die Implementierung einer inneren Klasse beim Erweitern einer äußeren Klasse

Question

Ich frage mich, ob es möglich ist, Clients zu zwingen, eine Implementierung einer inneren Klasse bereitzustellen, wenn sie eine neue Implementierung der äußeren Klasse definieren.

Um die Situation besser zu erklären: Ich habe eine abstrakte Klasse

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. 

Jetzt kann der Kunde eine Implementierung eines ImmutablePolynomial bereitzustellen, um eine bestimmte Datenstruktur unter Verwendung von zB Speicherverbrauch zu reduzieren, indem Sie diese Klasse erweitern. Wie kann ich den Client zwingen, auch eine Implementierung eines Innerclass Implementing Iterator bereitzustellen, sodass die Summe der statischen Methode in ImmutablePolynomial auch mit der vom Client bereitgestellten Implementierung funktioniert?

Auch wenn das eine schlechte Idee/Antipattern ist/gibt es eine bessere Alternative bitte sag es mir. Ich mache das, um meine Programmierung zu verbessern.

Edit 1: Entfernen Sie das Feld

geschützt Sammlung Begriffe

, wie in den Kommentaren adviced wird. Edit 2: make Methode

iterator()

abstrakt wie in den Kommentaren adviced ist

Answer 1

Da die ImmutablePolynomial Klasse abstrakt ist, so dass Sie nie ein Objekt, dessen Klasse ist ImmutablePolynomial, und vorausgesetzt, Sie wollen nicht Instanzen von ImmutablePolynomial 's Unterklassen Klasse ImmutablePolynomial.TermIterator zu verwenden, wann würde ImmutablePolynomial.TermIteratorjemals verwendet werden? Es ist sinnlos, es als innere Klasse zu implementieren.

Wie @Tassos in Kommentaren vorgeschlagen, deklarieren Sie stattdessen TermIterator als Schnittstelle; Dies kann in der Klasse ImmutablePolynomial geschachtelt werden oder nicht, wie Sie bevorzugen. Machen Sie auch ImmutablePolynomial.iterator() abstrakt.

In dem Maße, in dem Sie konkrete Methoden in ImmutablePolynomial haben, die sich auf den Iterator stützen, implementieren Sie sie gegen die Schnittstelle und nicht gegen eine bestimmte Implementierung. Das ist der einzig vernünftige Ansatz, wenn Sie Subklassen nicht nur erlauben, sondern auch benötigen, dass sie ihre eigene Implementierung bereitstellen.