Wie kann eine untergeordnete Schnittstelle die Implementierungen ihrer Eltern wiederverwenden?

Question

Kürzlich hatte ich ein Interview und mir wurde die folgende Frage gestellt. Angesichts der folgenden Klasse/Interface-Struktur:

Frage:

Wie eine Schnittstelle implementieren kann EmployedStudent Code von StudentImpl und EmployeeImpl wiederzuverwenden.

Ich schlug vor, Mitarbeiter und Student in meine Implementierung zu komponieren.

Basierend auf der Reaktion des Interviewers glaube ich nicht, dass sie die beste Lösung gefunden haben. Ich habe viel darüber nachgedacht, aber ich kann mir keine andere Lösung ausdenken.

Answer 1

Da Java keine Mehrfachvererbung unterstützen, Sie könnte/sollte

• entweder ein Feld für jede der gewünschten Super
• oder leiten sich von einer übergeordneten Klasse und haben ein Feld für die anderen.

Die Felder werden dann durch "unsere" Implementierung der jeweiligen Methoden bezeichnet.

Dies ist einer der design patterns from the GoF, ich denke, es ist die Proxy pattern.

Answer 2

Erstellen Sie eine Klasse, die sowohl Employee als auch Student implementiert. Erstellen Sie in Ihrer Klasse eine Instanz von EmployeeImpl und StudentImpl. Lassen Sie Ihre Klasse dann alle Methodenaufrufe an eines der Objekte delegieren.

public class EmployedStudent implements Employee, Student { 

    private EmployeeImpl employee = new EmployeeImpl(); 
    private StudentImpl student = new StudentImpl(); 

    public int getSalary() { 
    return this.employee.getSalary(); 
    } 

    public float getAverageGrade() { 
    return this.student.getAverageGrade(); 
    } 

} 

Answer 3

Mit Java 8 können Sie Code in die Schnittstelle selbst verschieben. Das löst das Problem der "Mehrfachvererbung".

Answer 4

Während die Schnittstelle Segregations Prinzip manchmal hilfreich sein kann, und einige Leute spotten über die Idee von Schnittstellen, die nicht versprechen, dass alle Implementierungen alle Mitglieder unterstützen, würde ich vorschlagen, dass es hilfreich sein kann Student und Employee Schnittstellen haben welche beinhalten isStudent und isEmployee Mitglieder, und dann haben Person implementieren beide Schnittstellen; einige Methoden wie giveRaise() sollten nicht auf jemanden funktionieren, der kein Angestellter ist, aber andere wie getOutstandingPay() sollten gut funktionieren (wenn jemand kein Geld verdient hat, sollte die Methode einfach Null zurückgeben).

Obwohl es hässlich erscheinen mag, alle Person Objekte mit Methoden zu komplizieren, die für viele von ihnen nicht anwendbar sind, vermeidet ein solches Design Schwierigkeiten für den Fall, dass ein Student eingestellt wird oder ein Mitarbeiter anfängt Klassen zu nehmen. Getrennte Klassen für Student, Employee und StudentEmployee, auch wenn man so leicht tun könnte, würde erfordern, dass ein Student, die einen Job mit einer neuen Objektinstanz ersetzt werden um ein StudentEmployee zu werden. Im Gegensatz dazu kann man, wenn man eine Person Klasse hat, deren Instanzen möglicherweise mit Methoden wie giveRaise umgehen können, mit Situationen umgehen, in denen sich die Fähigkeiten von Objekten während ihrer Lebensdauer ändern.

Answer 5

Sie könnten also implements Employee, Student intern sowohl an EmployeeImpl als auch an StudentImpl delegieren, aber auch von einer Implementierungsklasse erben.

Nun ist die Klasse Name EmployedStudent (StudyingEmployee oder BothEmployeeAndStudent nicht) schlägt vor:

class EmployedStudent extends StudentImpl implements Employee { 
    Employee asEmployee = new EmployeeImpl(); 

Ja, ein kleines bisschen effizienter als nur auf eine andere Klasse zu delegieren.

Die Use-Case ist jedoch weit davon entfernt realistisch: alle Arten von Kombinationen denkbar mehrere Klassen sind. In diesem Fall ist Ihre Lösung universeller. Wirklich universell, ist ein Lookup-Mechanismus:

public class Person { 
    public <T> T as(Class<T> klazz) { ... } 
} 

Person person = ...; 
Student asStudent = person.as(Student.class); 
if (asStudent != null) { 
    ... 
} 
Employee asEmployee = person.as(Employee.class); 
if (asEmployee != null) { 
    asEmployee.quitJob(); 
    asEmployee = person.as(Employee.class); // null 
} 

Das ist ein Lookup-Funktionen ist. Es in der Regel eine umständliche Vererbungshierarchie ersetzen kann, sagen von Fahrzeug, RoadVehicle, SwimmingVehicle (Boot), FlyingVehicle (Flugzeug), WaterAirplane (?), AmphibianTank (?) Von Fähigkeiten Schwimmen mit, Fliegen, Fahren.

Der Unterschied ist die gesamte Entkopplung.