Ich versuche, ein Framework zu erstellen, das es den Leuten ermöglicht, unsere Kernfunktionalität durch die Implementierung einer Schnittstelle zu erweitern. Unten ist ein dumbed down Beispiel dieser Schnittstelle.
%Vor%Vor kurzem haben wir uns entschieden, diese Schnittstelle zu ändern (ich weiß, dass ich keinen abhängigen Code ändern sollte, aber die Wahrheit ist, dass wir noch keine Drittanbieter haben, die diese Schnittstelle implementieren, also haben wir die Chance auf ein "do -Über "um diese Schnittstelle korrekt zu implementieren).
Wir müssen dieser Schnittstelle zwei weitere Parameter hinzufügen, damit unsere Software korrekt funktioniert. Zwei Arten, an die wir denken, sind, sie einfach so zur Signatur hinzuzufügen:
%Vor%oder indem Sie ein Parameterobjekt wie dieses erstellen
%Vor%und fügen Sie sie am Ende der Methode wie folgt hinzu:
%Vor%Ich suche nach einer Art von Anleitung, auf welchem Weg der "richtigste" Weg ist. Ich kann Vor- und Nachteile in beiden Kategorien sehen, aber ich möchte nicht, dass meine Vorurteile mich auf den falschen Weg führen.
Einige meiner Hauptanliegen sind:
Ich weiß nicht einmal, welche Frage ich online stellen sollte, um Anleitung für dieses Problem zu bekommen. Ich habe das Gefühl, dass die Antwort "hängt davon ab" (auf Dinge wie wie p1-p5 zu dem Zweck der GetData () -Funktion), aber kann jemand mich auf eine Liste von Fragen zeigen, die ich bitten sollte, um mich zu bewerten ob eine Lösung besser ist als die andere?
Lass mich versuchen, das zu beantworten. Lassen Sie uns Ihre Optionen bewerten:
1) Wenn die folgende Schnittstelle
%Vor%ist kaputt:
a) und sollte überhaupt nicht verwendet werden, dann sollten Sie die Implementierer zwingen, es neu zu schreiben. Ändern Sie die Methodendefinition.
%Vor%b) aber Sie müssen nur die Benutzer ermutigen, neue Definition zu verwenden, dann können Sie eine neue Überladung erstellen und ihnen mitteilen, dass die erste veraltet ist.
%Vor%Über Ihre neue Definition gibt es keine One-Stop-Lösung, die jemand geben kann, ohne das Modell zu kennen, aber Sie fragen sich,
I) " Können die Parameter selbst eine einzelne Entität darstellen, wenn sie kombiniert werden? Bedeutet es etwas in der realen Welt, eine Einheit Ihrer Parameter zu haben? " Wenn ja, machen Sie es so. Wenn nicht, nicht. Ich denke, man sollte sich darauf verlassen, in so abstrakten Ebenen zu denken, wenn man sich in einem solchen Dilemma befindet. Ich bin nicht sicher, was ist der Punkt in Clubbing bool p4 und DateTime p5 . Sie sollten jene Parameter vereinsamen, die selbst etwas im wirklichen Leben darstellen. Wenn keine Kombination von diesen Sinn ergibt, dann belasse es als solches. Sie werden mehr Erfolg haben, solche Clubbings auf solch logische Art zu denken. Wohlgemerkt, Sie überlassen Ihre Definition anderen Programmierern, und um ihre Arbeit zu erleichtern, sollte Ihre Methodensignatur sehr sehr logisch sein.
II) Kann die Klasse mehr Dinge tun, als nur Daten zu speichern? Hier sollte die Klasse Option sein.
III) Muss ich nur die Klassendefinition kontrollieren und nicht die Implementierung? ? In diesem Fall definieren Sie einfach eine öffentliche Schnittstelle Ihrer Eingaben und überlassen die Implementierung dem Kunden.
IV) Sollten zukünftige Änderungen an meiner Schnittstelle die bestehende Implementierung nicht durchbrechen? Überladung ist Ihr Weg zu gehen.
Nehmen wir an, Sie haben zwei Möglichkeiten, lassen Sie die Signatur flach bleiben oder zum Club.
1) Ohne Clubbing:
a) Weniger Code, Reduktion einer anderen Ebene.
b) Keine Notwendigkeit, eine andere Klasse der Öffentlichkeit zugänglich zu machen.
2) Mit Clubbing:
a) Vermittelt ein besseres Verständnis des Modells, um in die Funktion zu gehen - Ihre Absicht ist klar.
b) In Zukunft einfach skalierbar, wenn Sie optionale Details zum Konstruieren der neu gebildeten Klasse hinzufügen müssen. Sagen wir, Sie haben eine Klasse
%Vor%und Schnittstelle
%Vor%Jetzt möchten Sie vielleicht optionale Details wie ein bool und eine DateTime hinzufügen. Da sie optional sind, müssen Sie sie nicht im Konstruktor erzwingen. Sie können immer noch den gleichen Konstruktor haben und dem Benutzer das Recht geben, ihn bei Bedarf außerhalb des Konstruktors zu ändern.
%Vor%Die Schnittstelle kann immer noch gleich sein. Wie gesagt, der Anstoß, etwas von dieser Art abzuleiten, hängt leider von Ihrem Modell ab. Kurz gesagt, wenn eine Gruppierung etwas bedeuten kann, machen Sie daraus eine Klasse oder Schnittstelle (abhängig davon, wer die Logik steuert).
Tags und Links c# parameter-object