Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Abstrakte Klasse innerhalb einer anderen Klasse
pollito
myCSharp.de - Member

Avatar #avatar-3521.gif


Dabei seit:
Beiträge: 222

Themenstarter:

Abstrakte Klasse innerhalb einer anderen Klasse

beantworten | zitieren | melden

Bitte nicht steinigen wegen dieser Frage, aber ich komme selbst nicht drauf! Danke ;-)

Im unteren Code habe ich zwei abstrake Methoden in einer Basisklasse. Diese muss ich in abgeleiteten Klassen implementieren – bis hierhin alles klar. Wie kann ich aber erzwingen, dass eine von Base abgeleitete Klasse die innere Klasse "innerClass" implementiert?


public abstract class Base
{
	public abstract void Func1();
	public abstract void Func2();

	public class innerClass { }
}

public class Derived : Base
{
	public override void Func1()
	{
		return;
	}
	public override void Func2()
	{
		return;
	}
}
Geht das oder habe ich ein Brett vor dem Kopf?

Lieben Dank!
René
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.752

beantworten | zitieren | melden

Keine Ahnung, was Dein Ziel ist - leider erklärst Du es auch nicht. Kannst das bitte nachholen? Siehe [Hinweis] Wie poste ich richtig?

"InnerClass" kannst Du natürlich nirgends erzwingen, weil das mit Vererbung auch nichts zutun hat.
private Nachricht | Beiträge des Benutzers
T-Virus
myCSharp.de - Member



Dabei seit:
Beiträge: 1.961
Herkunft: Nordhausen, Nörten-Hardenberg

beantworten | zitieren | melden

Was du mit der innerClass vorhast, kann so nicht funktionieren.
Die Implementierung muss im aktuellen Stand in BaseClass erfolgen, was ja den Sinn deines Vorhabens schon im Grunde wegnimmt.

Wenn du aber eine Klassen Implementierung über BaseClass mitgeben willst, müsstest du eher eine Eigenschaft haben.
Dann brauchst du aber eher ein Interface, um eine Implementierung zu erzwingen.

Aber ohne zu wissen, was das Endergebnis sein soll, kann man vieles über unzählige Wege umsetzen.


public abstract class Base
{
    // Eigenschaft für die Implementierung, die in der ergebenden Klasse zugewiesen werden muss
    IInnerClass { get; set; }

    // Interface für die Implementierung
    public interface IInnerClass
    {
        // Hier Methoden/Eigenschaften einfügen, die Implementiert werden sollen!
    }
}

public class Derived : Base
{
    // Hier die Implementierung zuweisen
    public IInnerClass { get; set; }
}

T-Virus
Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.752

beantworten | zitieren | melden

Code Beispiele als Antwort machen immer wenig Sinn, wenn man das Ziel nicht kennt. Ich vermute hier einen (grobe?) Designfehler an anderer Stelle, sodass der Wunsch nach der InnerClass nur ein Folgefehler sein könnte.
Daher hab ich entsprechend um die Zielbeschreibung gebeten, was man in einem Forum immer schreiben sollte.
Zitat von T-Virus
Wenn du aber eine Klassen Implementierung über BaseClass mitgeben willst, müsstest du eher eine Eigenschaft haben.
Also so ganz kann ich Deinem Code Beispiel nicht folgen.
Abstrakte Inhalte definiert man eigentlich über abstrakte Eigenschaften; das Interface spielt hier eine untergeordnete Rolle, sofern es um die Abstrahierung selbst geht und nicht um die Implementierung.
Gewusst wie: Definieren von abstrakten Eigenschaften – C#-Programmierhandbuch

Wenn es logische Inhalte sind, dann können das aber genauso gut abstrakte Methoden sein; ein Zwang auf eine Eigenschaft gibts nicht.
Gibt auch noch andere Architekturmechanismen für sowas, dazu müsste man aber das Ziel kennen.
private Nachricht | Beiträge des Benutzers
pollito
myCSharp.de - Member

Avatar #avatar-3521.gif


Dabei seit:
Beiträge: 222

Themenstarter:

beantworten | zitieren | melden

Nun, wenn das nicht vorgesehen ist, dann lassen wir es. Der Hintergrund war folgender:

Die Basisklasse bietet Methoden für den Zugriff auf unterschiedliche Datenbanksysteme – diese sind vom jeweiligen Datenbanksystem unabhängig. Zusätzlich definiert die Basisklasse abstrakte Methoden, die in den abgeleitetren Klassen implementiert werden. Diese abgeleiteten Klassen sind dagegen abhängig vom Datenbanksystem und bilden die Schnittstelle zwischen dem spezifischen Datenbanksystem und der höheren datenbankunabhängigen Abstraktionsebene. Bis hierhin also was ganz Normales.

Während der Entwicklung habe ich festgestellt, dass ich in den abgeleiteten Klassen für die datenbankspezifische Verwaltung weitere Klassen benötige. Die Implementierung dieser Klassen ist je nach Datenbanksystem sehr unterschiedlich – dennoch wollte ich der Übersichtlichkeit halber, die gesamte Funktionalität in gleichlautende Klasse kapseln. Also eher eine erzwungene Kosmetik für Wartung, Weiterentwicklung und Dokumentation.

Wenn das nicht geht, dann muss man es nicht übers Knie brechen. Es gibt dann eine Arbeitsanweisung, wie neue abgeleitete Klassen (neue Schnittstellen zu anderen Datenbanksystemen) auszusehen haben.

Vielen Dank und liebe Grüße!
René
private Nachricht | Beiträge des Benutzers
chilic
myCSharp.de - Experte



Dabei seit:
Beiträge: 2.102

beantworten | zitieren | melden

Ich vermute die *public* InnerClass wird nicht sehr hilfreich für einen Anwender deiner Basisklasse sein. Denn wer die Basisklasse nutzt, will in der Regel nicht wissen welche abgeleitete Klasse tatsächlich dahinter steckt und kann daher auch nicht auf die jeweils spezielle InnerClass zugreifen.
Daher ist es für den Anwender der Basisklasse egal wie diese Klasse heißt.

Dem Autor der abgeleiteten Klassen würde ich auch keine solchen Vorschriften machen, selbst wenn ich könnte. Der soll das nutzen was er braucht und wie er es braucht. Vielleicht braucht eine abgeleitete Klasse mehrere innere Klassen, oder auch mal gar keine.
Oder der Autor möchte die innere Klasse(n) in verschiedenen Ableitungen ausdrücklich verschieden benennen, um zu zeigen in welcher Ableitung er sich gerade befindet. Im Beispiel der Datenbankklassen vielleicht einmal MysqlInnerClass und dann SqlserverInnerClass oder PostgresInnerClass.
private Nachricht | Beiträge des Benutzers
pollito
myCSharp.de - Member

Avatar #avatar-3521.gif


Dabei seit:
Beiträge: 222

Themenstarter:

beantworten | zitieren | melden

Du hast Recht, wenn die Klassen von externen Entwicklern abgeleitetr werden sollen. Der Autor der abgeleiteten Klassen sind jedoch wir :-) Z. B. behandeln MySQL und Guptas SQLBase die Eigenschaften von Datenbankfeldern zum Teil ziemlich unterschiedlich. Dennoch wollte ich erreichen, dass diese Behandglung in einer gleichnamigen Klasse stattfindet, um einfach Wartung, Weiterentwicklung und Dokumentation ein bisschen zu vereinheitlichen. Mehr verbirgt sich nicht dahinter und wir wollen keine Raketenwissenschaft daraus machen.

Auch dir vielen Dank und ein schönes Wochendende!
René
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.752

beantworten | zitieren | melden

Zitat von pollito
Dennoch wollte ich erreichen, dass diese Behandglung in einer gleichnamigen Klasse stattfindet, um einfach Wartung, Weiterentwicklung und Dokumentation ein bisschen zu vereinheitlichen.
Das ist schon irgendwie schizophren.
Auf der einen Seite wollt ihr Flexibilität durch verschiedene Provider, willst Dir dann aber selbst ein starres Konstrukt an Sub-Classes bauen, wovon gar nicht ersichtlich sein kann, ob jede Implementierung tatsächlich jede Subclass braucht / verwenden kann.
Für mich hört sich das nach wie vor nach einem Fehler in der Architektur drüber an.
private Nachricht | Beiträge des Benutzers
pollito
myCSharp.de - Member

Avatar #avatar-3521.gif


Dabei seit:
Beiträge: 222

Themenstarter:

beantworten | zitieren | melden

Falsch verstanden. Ich habe das oben erklärt – steht alles oben. Es ging um die Möglichkeit der internen Wartung, Weiterentwicklung und Dokumentation.

Dir auch ein schönes Wochenende!
René
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.752

beantworten | zitieren | melden

Nö, hab ich nicht falsch verstanden - hab schon auch den oberen Teil gelesen; aber danke der Unterstellung :-)
private Nachricht | Beiträge des Benutzers
chilic
myCSharp.de - Experte



Dabei seit:
Beiträge: 2.102

beantworten | zitieren | melden

Abgesehen von Sinn oder Unsinn dieses Vorhabens, aber wenn die Umsetzung dieser Klassen in der selben Firma erfolgt, sollte doch eigentlich eine Teambesprechung ausreichen um die Programmierung einheitlich zu gestalten ;-)
private Nachricht | Beiträge des Benutzers
pollito
myCSharp.de - Member

Avatar #avatar-3521.gif


Dabei seit:
Beiträge: 222

Themenstarter:

[Gelöst] Abstrakte Klasse innerhalb einer anderen Klasse

beantworten | zitieren | melden

Zitat von chilic
Abgesehen von Sinn oder Unsinn dieses Vorhabens, aber wenn die Umsetzung dieser Klassen in der selben Firma erfolgt, sollte doch eigentlich eine Teambesprechung ausreichen um die Programmierung einheitlich zu gestalten ;-)
Ja, ich schrieb bereits, dass dafür eine Arbeitsanweisung reichen würde. Es wäre aber ein Tick schöner, diese Vorgabe mit einer Art Vorlage programmtechnisch zu steuern.

René
private Nachricht | Beiträge des Benutzers
Palladin007
myCSharp.de - Member

Avatar #avatar-4140.png


Dabei seit:
Beiträge: 1.758
Herkunft: Düsseldorf

beantworten | zitieren | melden

Naja, Du kannst es insofern steuern, indem Du die Inner-Classes protected abstract machst.
Die Outer-Class will dann auf irgendeine Weise eine Instanz davon und der Entwickler stellt fest, dass er keine andere Möglichkeit hat, als von dieser Inner-Class abzuleiten und auslagern als normale Klasse geht auch nicht, weil protected.

Aber ich sehe das ähnlich:
Dem liegt vermutlich ein Architektur-Problem zugrunde.
Und ich frage mich auch: Warum nicht einfach ein Interface neben die Klasse legen?
private Nachricht | Beiträge des Benutzers
T-Virus
myCSharp.de - Member



Dabei seit:
Beiträge: 1.961
Herkunft: Nordhausen, Nörten-Hardenberg

beantworten | zitieren | melden

Der Ansatz mit dem Interface, war ja mein erster Gedanke auch wenn der Code das nicht ganz klar vorgibt.
Aber damit kann man das Problem lösen.
Jede abgeleitete Klasse müsste dann wieder eine eigene interne Implementierung umsetzen und dann diese Instanzieren und der jeweiligen Ableitung intern mitgeben.

T-Virus
Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
private Nachricht | Beiträge des Benutzers
Palladin007
myCSharp.de - Member

Avatar #avatar-4140.png


Dabei seit:
Beiträge: 1.758
Herkunft: Düsseldorf

beantworten | zitieren | melden

Wenn die Implementierungen wirklich so unabhängig voneinander sind, wie es klingt, würde ich eigene Assemblies daraus machen.
Eine Datenbank-Schicht = eine Assembly und alles, was intern genutzt wird, ist internal.
Das macht mMn. auch den Überblick deutlich leichter.
private Nachricht | Beiträge des Benutzers
T-Virus
myCSharp.de - Member



Dabei seit:
Beiträge: 1.961
Herkunft: Nordhausen, Nörten-Hardenberg

beantworten | zitieren | melden

Der Vorschlag klingt insgesamt am sinnvollsten.
Dadurch könntet ihr per Interfaces den Aufbau vorgeben.
Spezifische Implementierungen mit Sonderwürsten wären dann auch gut verpackt.

Im Grund würdet ihr konzeptionel dann den gleichen Weg gehen wie die ADO .NET Treiber.
Dort gibt es auch gewissen Interfaces (DbConnection, DbCommand etc.) die eben grobe Vorgaben machen und nur die Basisfunktionalität vorschreibt.
Gegen diese müssen die Assemblies nur programmiert sein, dann könnt ihr einfach austauschbar machen je nachdem welche DB ihr verwendet.
Dürfte den Code um einiges übersichtlicher und sauberer gestalten.

T-Virus
Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
private Nachricht | Beiträge des Benutzers
pollito
myCSharp.de - Member

Avatar #avatar-3521.gif


Dabei seit:
Beiträge: 222

Themenstarter:

beantworten | zitieren | melden

Lieben Dank euch beiden! Ja, so ist die Software auch aufgebaut. Das funktioniert auch gut. Mein Wunsch war/ist, wie mehrfach erläutert, eher etwas kosmetisches.

Viele Grüße und bleib gesund!
René
private Nachricht | Beiträge des Benutzers