Teilweise Implementierung von abstrakten Methoden

FinnO · Verfasst: So 10.03.13 17:30

Moin,

vorab sage ich gleich: Der Titel ist mir nicht wirklich gelungen.

Ich muss bedingt durch eine Plugin-Umgebung eine Klasse von einer Abstrakten Klasse ableiten. Nun macht es aber keinen Sinn, einzelne Abstrakte Methoden innerhalb derselben Klasse zu implementieren, es wäre viel besser, könnte ich diese in einer Art Unterklasse implementieren. Die Programmiersprache ist übrigens Java, mir würde allerdings schon reichen, wenn ihr mich mit einigen Vokabeln versorgen könntet, damit ich das Problem etwas besser googlen kann.

Ich umrande das Ganze einmal mit einem Beispiel.

markieren

JavaScript-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:

public abstract class Ursprung{
  public abstract int foo(); //Diese Funktion ist kontextbedingt unsinnig in der abgeleiteten Klasse
  public abstract int bar(); //Diese Funktion macht in der abgeleiteten Klasse Sinn.
}

public class Abgeleitet{
  public int bar(){doSomething();}

  //Hier hätte ich jetzt gerne eine Alternative dazu, foo() implementieren zu müssen. 
  //Abgeleitet darf jedoch nicht abstrakt sein. 
}

Ich weiß, dass ich theoretisch die Methode bar() ja in einer Vererbungsebene davor implementieren könnte, allerdings macht das für diese Helferfunktionen irgendwie vom Gefühl her keinen besonders guten Eindruck.

Ideen?

Ralf Jansen · Verfasst: So 10.03.13 18:07

Lege eine abstrakte EinWenigMehrAlsUrsprung Klasse dazwischen die foo implemementiert und leite Abgeleitet von dieser ab?

Kann ich deinen einleitenden Satz so verstehen das du Ursprung nicht ändern kannst? Ansonsten würde ich sagen gehört foo da raus.

FinnO · Verfasst: So 10.03.13 19:54

Ralf Jansen hat folgendes geschrieben :

Lege eine abstrakte EinWenigMehrAlsUrsprung Klasse dazwischen die foo implemementiert und leite Abgeleitet von dieser ab?

Das ist ja genau das, was ich vermeiden will - nicht aus rationalen Gründen, sondern aus dem Grund, dass foo() Nur "niedere Dienste" verrichtet.

Ralf Jansen hat folgendes geschrieben :

Kann ich deinen einleitenden Satz so verstehen das du Ursprung nicht ändern kannst? Ansonsten würde ich sagen gehört foo da raus.

Jap, es handelt sich um ein VST-Plugin.

LG

Ralf Jansen · Verfasst: Mo 11.03.13 11:34

Zitat:

Das ist ja genau das, was ich vermeiden will - nicht aus rationalen Gründen, sondern aus dem Grund, dass foo() Nur "niedere Dienste" verrichtet.

Was würdest du denn gern stattdessen tun? Es nicht zu implementieren fällt flach. Eine Abgeleitet Instanz muss auch eine vollständige Ursprung Instanz darstellen sonst haben wir eins der grundlegensten OOP Prinzipien verletzt das ich mir vorstellen kann. Das einzige Möglichkeit die du hast ist foo wo anders zu implementieren und da Java meines Wissens nach keine Mixins, Traits oder irgendwas aus der Ecke unterstützt ist dein Mittel der Wahl die Vererbungshierarchie in der du irgendwas einschieben kannst das foo enthält.

Blup · Beiträge: 173 Erhaltene Danke: 43

Scheinbar handelt es sich um zwei verschiedene Interface.
Das eine beschreibt eine Klasse wie diese extern erwartet wird.
Das andere ist ein internes nach deiner Vorstellung.

Du könntest eine finale Klasse schreiben, die das externe Interface implementiert.
Dieses müsste eine Membervariable vom Typ des internen Interface besitzen.
Einzige Aufgabe dieser Klasse ist, externe Aufrufe an das interne Interface weiterzuleiten.

Die eigentlich Implementation kann dann jeweils auf Basis deines internen Interface erfolgen.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme