abstract static-Methode bzw. abstrakter Konstruktor
-
Wenn ich die vielen
if (s.StartsWith("B")) liste.Add(new B(s));durch viele
creators.Add("B", (param) => new B());ersetze, habe ich glaube nichts gewonnen. Das Auslagern von dieser "String"-"Datentyp"-Zuordnung in ein Dictonary hätte nur dann Sinn, wenn ich es noch an anderer Stelle brauche.
Mein Code soll einerseit so kurz(Wenig Variablen, Wenig Anweisungen) wie möglich sein, anderseits soll er so viel wie möglich gegen Unachtsamkeitsfehler geschützt sein. Ich weiß, die Anforderungen klingen Hart, aber mir gehts bei meinen Programm jetzt mal vorranig darum einfach nur Programmierprinzipien/Designpattern zu üben.
-
Factories sind Designpattern. Ob du das nun in eine Factory packst oder in ein Dictionary, an IRGENDEINER Stelle musst du konkrete Implementationen liefern. Und das kannst du nur indem du diese irgendwo definierst.
-
Ja, das habe ich momentan durch die vielen
if (s.StartsWith("B")) liste.Add(new B(s));-Zeilen.
Ich möchte den Code nicht durch zusätzliche Variablen/Klassendefinitionen aufblähen.(Hat hier jemand übrigens Blähungen von euch?
)
-
XMAMan__ schrieb:
Ja, das habe ich momentan durch die vielen
if (s.StartsWith("B")) liste.Add(new B(s));-Zeilen.
Ich möchte den Code nicht durch zusätzliche Variablen/Klassendefinitionen aufblähen.(Hat hier jemand übrigens Blähungen von euch?
)Ja extreme.
Zurueck zum Thema:
Nun ja, die If sind ja ziemlich Wartungsunresistent. Wenn du eine Factory anbietest wo "jeder" seine Implementierungen registrieren kann und spaeter abrufen kann, uebergibst du die Verantwortung an denjenigen der deine Factory benutzt. Deine Aufgabe ist es nun die Rahmenbedingungen zu definieren. Das kannst du entweder ueber ein Interface machen, wie es dot bereits angemerkt hat. Oder du verpackst das erzeugen in einen Funktor der einen von dir definierten Rueckgabewert haben muss(wie z.B. eine Abstrakte Klasse, oder Interface). Alles andere ist Unsinn.