Wo Delgates in .Net-Lösung

Question

Ich habe eine C# .Net-Sammlung von Lösungen, die als ein Beweis für das Konzept gestartet, und hat sich zu fast 15 verschiedenen Projekten gewachsen. Ich bin gerade dabei, die gesamte Produktfamilie neu zu schreiben und versuche Best Practices nach bestem Wissen mit einer zukunftssicheren Organisation zu pflegen.

Ich habe einige Nachforschungen angestellt, und ich bin immer noch unklar, wo es am besten ist, die Delegierten in einem Multiprojekt-Produkt zu halten, um die Notwendigkeit eines Refactorings in der Zukunft zu minimieren. Ich würde annehmen, dass der allgemeine Konsens ist, dass Sie sie überall hin platzieren, was für den Anwendungsfall sinnvoll ist, aber im Allgemeinen finde ich, dass es den besten Weg gibt, alles in einer Lösung zu strukturieren, um Probleme zu minimieren, positive Modularität zu fördern Instandhaltung.

In vielen Fällen wird empfohlen, dass sie mit ihrem Einsatzort reisen; vermutlich im Namespace oberhalb der Klassendatei deklariert, was in meinem Fall in meine gemeinsame Bibliothek mit den allgemeinen Schnittstellen übersetzt würde, die die Ereignisse vorschreiben. Ich habe derzeit Delegaten in einer eigenen Datei in einem "Delegate" -Namespace. Gibt es eine Verstimmung, die ich dadurch mache, oder verkompliziere ich den Anwendungsfall für die Delegierten - oder stimmt das mit den derzeitigen Nutzungserwartungen überein?

Ich habe die typischen Suchen durchgeführt, aber habe nichts glaubwürdiges noch wesentlich gefunden; Dies könnte jedoch eine Folge der schlechten Keyword-Auswahl sein.

Answer 1

würde ich der allgemeine Konsens nehmen ist, dass man sie überall platzieren, die sinnvoll für den Anwendungsfall macht, aber im Allgemeinen Ich fühle mich gibt es einen besten Weg, alles in einer Lösung zu strukturieren Probleme zu minimieren, fördern positive Modularität und einfache Wartung.

Nun ja, im allgemeinen Fall können Sie einfach alles wo immer Sie es wünschen. Die Probleme beginnen jedoch, wenn Sie in einem Team arbeiten. In einem Team müssen andere Leute die Struktur des Programms verstehen, um effektiv Code zu erstellen. Das bedeutet Konsequenz, was das Endziel ist.

Also, es ist nicht nur eine Frage der Intuition; In allen Unternehmen, in denen ich gearbeitet habe, habe ich angefangen, einen Kodierungsstandard zu schreiben und diesen überall aggressiv durchzusetzen. In diesem Codierungsstandard, habe ich in der Regel eine Tonne gute/schlechte Praktiken bei threading, den statischen Einsatz, die Platzierung von Variablen/Klassen, etc.

IIRC Link http://se.inf.ethz.ch/old/teaching/ss2007/251-0290-00/project/CSharpCodingStandards.pdf und https://msdn.microsoft.com/en-us/library/ff926074.aspx wird Ihnen einen Vorsprung geben, obwohl die erstere ein bisschen veraltet und beide beantworten deine Frage nicht wirklich. Es könnte jedoch mit dem helfen, was Sie auf lange Sicht erreichen wollen.

[...] Ich habe derzeit Delegierte in ihre eigene Datei, in einem 'Delegate' Namespace. Gibt es ein Versehen, das ich mache, indem ich das tue, oder überbebee ich den Anwendungsfall für Delegierte - oder ist das inline mit aktuellen Nutzungserwartungen?

Eine gemeinsame Bibliothek mit Schnittstellen ist sinnvoll. Eine Schnittstelle ist im Wesentlichen ein Vertrag zwischen "Client" und "Server", der ein wichtiges Gut zur Entkopplung einer Software ist.

Sie müssen an dieser Stelle feststellen, dass der "Schnittstellen" -Teil eine funktionale Zerlegung ist, keine technische. Mit anderen Worten: die Tatsache, dass Sie eine "Interface" -Bibliothek benötigen, ist eine Frage von Vertrag, nicht von technische Konstrukte. Daher sehe ich nicht, warum Sie jemals Klassen in einen "Klassen" -Ordner stellen würden und warum Sie Delegierte in einen "Delegierten" -Ordner stellen würden. Kurz gesagt, ein Delegiertenordner macht für mich keinen Sinn. Leg das Zeug dahin, wo es hingehört.

An diesem Punkt müssen Sie eine Entscheidung treffen. (1) Sie können einen Delegaten in einer einzigen Datei ablegen, (2) Sie können einen Delegaten in die Klassendatei einfügen, in der er verwendet wird (normalerweise verwende ich Delegaten für einen einzigen Zweck), (3) können Sie beides abhängig von Multi-Zweck und (4) können Sie einzelne Delegierten innerhalb der Klasse verschachtelt setzen. Das bedeutet im Grunde, dass Sie einen Delegaten als Funktionszeiger behandeln und ihn nicht als echte "Klasse" sehen.

Mit Blick auf funktionale Dekomposition können Sie argumentieren, dass ein Funktionszeiger genau wie Methoden zu einer Klasse gehört.

So zu folgern. Persönlich wähle ich normalerweise die Option (2) oder (3), weil sie kurz, klar und prägnant ist und keinen Einfluss auf die Menge an "Tipparbeit" wie (4) hat. Kommissionierung (1) wird wahrscheinlich Ihre Anwendung mit kleinen Dateien aufblähen, die wenig oder keinen Zweck haben, was andere Entwickler verwirren wird.