Laden...

Parameter Klasse statisch vererben

Erstellt von dr4g0n76 vor 18 Jahren Letzter Beitrag vor 18 Jahren 5.035 Views
dr4g0n76 Themenstarter:in
2.921 Beiträge seit 2005
vor 18 Jahren
Parameter Klasse statisch vererben

Ich steh gerade auf dem Schlauch. Liegt wohl daran, dass ich gestern ein Garagentor auf den Kopf geknallt bekommen habe.

Folgendes Designproblem (in .NET 1.1):

Ich habe verschiedene Klassen, wie Move, Close usw. die Aktionen beschreiben.
Alle sind von der Klasse Command abgeleitet.

Jetzt wäre es perfekt um mit der Klasse Parameters die Parameter für jede dieser Klassen zu setzen, in der Klasse Command eine statische Funktion á la

public static void SetParameters(Parameters parameters)

zu programmieren.

Nur sollte diese dann auch in den anderen Klassen automatisch vorhanden sein, so dass ich für jede Klasse klassenweit die Parameter setzen kann, statisch eben.

Wie mache ich das?

Interfaces? Oder gibt's wirklich einen Weg, wo das gewünschte Verhalten überall drin ist?

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

S
8.746 Beiträge seit 2005
vor 18 Jahren

Bahnhof. Mach mal ein winziges Beispiel.

dr4g0n76 Themenstarter:in
2.921 Beiträge seit 2005
vor 18 Jahren

Beispiel:


class Command
{
      [.. Methoden und Variablen blablabla...]
      public static void SetParameters(Parameters parameters);
}


class Move:Command
{
     [... Methoden und Variablen usw...]
     <- jetzt sollte hier auch SetParameters vorhanden sein, aber nur für diese Klasse
}

class Rename:Command
{
     [... Methoden und Variablen usw...]
    <- dito
}


So daß man mit

Move und Rename sind hier die Klassen, keine Objekte, da die Parameter ja automatisch für alle neuen Objekte gelten sollen.


Move.SetParameters(parameters);
Rename.SetParameters(parameters);

Hoffe es ist jetzt klarer.

EDIT: mir gefällt es einfach nicht in jede Klasse

public static void SetParameters(Parameters parameters)

definieren zu müssen.

einmal jeweils alle Parameter für die entsprechenden Klassensetzen kann

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

49.485 Beiträge seit 2005
vor 18 Jahren

Hallo dr4g0n76,

statische Methoden werden nicht vererbt. Interfaces kannst du nicht verwenden, weil du keine Instanz hast, das du auf Interface casten kannst. Ich denke, du hast da ein Problem. Kannst du wohl nur per Konvention machen oder per Instanzmethode, die aber die Paremeter in einem statischen Feld speichert.

herbivore

dr4g0n76 Themenstarter:in
2.921 Beiträge seit 2005
vor 18 Jahren

Klar Herbivore, das weiß ich ja. Trotzdem danke für den Hinweis 😉

Ich will ja nur wissen, wie mein Design aussehen müßte damit es paßt.

Oder bleibt mir doch nur die Lösung es für jede Klasse einzeln zu implementieren?

Vielleicht müßt ich auch ein Design-Pattern einsetzen.

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

49.485 Beiträge seit 2005
vor 18 Jahren

Hallo dr4g0n76,

Oder bleibt mir doch nur die Lösung es für jede Klasse einzeln zu implementieren?

das meinte ich mit per Konvention.

Einen weiteren Vorschlag habe ich schon gemacht.

herbivore

dr4g0n76 Themenstarter:in
2.921 Beiträge seit 2005
vor 18 Jahren

Hmm mal anders überlegt, vielleicht kann ja eine übergeordnete Klasse, die weiß welcher Parametersatz wozu gehört, jeder neuen Kreation eines Commands den Satz Parameter mitgeben. Hört sich für mich fast nach einem Factory-Pattern an.

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

49.485 Beiträge seit 2005
vor 18 Jahren

Hallo dr4g0n76,

du könntest dir in einem Dictionary (Hashtable) zu dem Klassennamen oder Klassentyp (Type) die jeweiligen Parameter merken. Aber schön finde ich das nicht.

herbivore

S
8.746 Beiträge seit 2005
vor 18 Jahren

Original von herbivore

statische Methoden werden nicht vererbt.

Hmm, bei mir werden die tadeslos vererbt....

dr4g0n76 Themenstarter:in
2.921 Beiträge seit 2005
vor 18 Jahren

.NET 1.1 oder 2.0? in 2.0 weiß ich das nicht, vielleicht geht das ja da?

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

49.485 Beiträge seit 2005
vor 18 Jahren

Hallo svenson,

dann verstehen wir vielleicht etwas anderes unter Vererbung. 🙂

Wenn U von O erbt, kann man die statische Methode O.M auch als U.M aufrufen. Es ist aber immer noch die Methode O.M die da aufgerufen wird. Klarer wird es vielleicht bei statischen Feldern. Diese gibt es (wie die Methoden) auch nur (einmal) in der Oberklasse und werden nicht an die Unterklasse vererbt, sprich es gibt sie nicht (nochmal) in der Unterklasse.

herbivore

dr4g0n76 Themenstarter:in
2.921 Beiträge seit 2005
vor 18 Jahren

@herbivore: genauso geht es mir auch. Schön fände ich, wenn die statische Methode vererbt werden würde, und das gewünschte Verhalten hätte, das ich beschrieben habe, dann würde es passen.

Also wie muss ich dann mein Design umändern oder anpassen, damit es schön wird?

ich weiß es immer noch nicht.

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

S
8.746 Beiträge seit 2005
vor 18 Jahren

Vererbung ist für mich, wenn ich Member von Oberklassen nutzen kann. Das andere ist für mich Polymorphie.

Statische Member sind nicht polymorph.

49.485 Beiträge seit 2005
vor 18 Jahren

Hallo svenson,

für mich ist Vererbung, wenn sich die geerbte Methode in der Unterklasse genauso verhällt, als wäre sie dort definiert (ggf. mal abgesehen von den Zugriffsrechten). Das ist bei statischen Methoden nicht der Fall. Aber nochmal: Vielleicht wird es klarer, wenn du statische Felder betrachtest.

herbivore

dr4g0n76 Themenstarter:in
2.921 Beiträge seit 2005
vor 18 Jahren

Vielleicht brauche ich auch ein Singleton? Das ist ja quasi "statisch" und kann trotzdem vererbt werden. Stimmt, das müßte es sein. Muß halt dann als ArrayMember

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

49.485 Beiträge seit 2005
vor 18 Jahren

Hallo dr4g0n76,

Singelton hatte ich verworfen weil wir ja über Klassen sprechen, die mehr als eine Instanz haben können.

herbivore

49.485 Beiträge seit 2005
vor 18 Jahren

Hallo svenson,

ok, wenn man sich die Warnmeldung CS0108 anschaut, ist die Microsoft-Sicht wohl, dass statische Methoden vererbt werden. Das ist aber m.E. Augenwischerei, weil statische Methoden in der Regel auf statischen Felder arbeiten und diese Felder nicht vererbt werden.

herbivore

dr4g0n76 Themenstarter:in
2.921 Beiträge seit 2005
vor 18 Jahren

Also gut, wenn Du singletons verworfen hast, fragen wir andersrum @herbivore:

wie würdest du das machen?

Ich finde bisher keine der angesprochenen Ansätze so interessant, daß ich sie als Lösungsansatz bisher sehen würde

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

P
939 Beiträge seit 2003
vor 18 Jahren

Warum nicht doch die Factory?

// Factory instanziieren.
CommandFactory factory = new CommandFactory();

// Commands registrieren.
factory.RegisterCommand("Move", typeof(MoveCommand), new MoveParameters());
factory.RegisterCommand("Exit", typeof(ExitCommand), new ExitParameters());

// Move-Command erzeugen.
MoveCommand move = (MoveCommand)factory.CreateCommand("Move");

Resultat: jedes MoveCommand-Objekt bekommt die selbe MoveParameters-Instanz gesetzt, die SetParameters-Methode kann problemlos in der Basisklasse Command definiert werden, erneute Definition in den Command-Ableitungen ist nicht erforderlich.

Spricht doch nichts dagegen. Flexibler als eine statische Methode ist es auf jeden Fall (auf statische Methoden, die den Zustand der Klasse ändern, würde ich ohnehin immer verzichten wollen).

Gruss
Pulpapex

49.485 Beiträge seit 2005
vor 18 Jahren

Hallo Pulpapex,

auf statische Methoden, die den Zustand der Klasse ändern, würde ich ohnehin immer verzichten wollen.

Wenn sie - wie im vorliegenden Fall - quasi (= per Konvention) readonly sind, halte ich das für unkritisch.

Damit will ich jedoch nichts gegen die Factory sagen.

herbivore