Sollte ich Namespace-Hinweise in Klassennamen aufnehmen?

Question

Wenn ich eine Reihe von Schnittstellen habe, die mehrere Implementierungen haben können (z. B. In-Memory, NHibernate, xml-basiert usw.), ist es dann sinnvoll, in den Klassennamen selbst Namespace-Hinweise anzugeben? Zum Beispiel:

MyDomain.Infrastructure.ISomeProvider
MyDomain.Infrastructure.ISomeOtherProvider
MyDomain.Infrastructure.IYetAnotherProvider

Das könnte ich dann haben:

MyDomain.Infrastructure.Impl.MemoryBased.SomeProvider
MyDomain.Infrastructure.Impl.MemoryBased.SomeOtherProvider
MyDomain.Infrastructure.Impl.MemoryBased.YetAnotherProvider
MyDomain.Infrastructure.Impl.XmlFileBased.SomeProvider // etc...
MyDomain.Infrastructure.Impl.NHibernate.SomeProvider // etc...

vs.

MyDomain.Infrastructure.Impl.MemoryBased.MemoryBasedSomeProvider
MyDomain.Infrastructure.Impl.MemoryBased.MemoryBasedSomeOtherProvider
MyDomain.Infrastructure.Impl.MemoryBased.MemoryBasedYetAnotherProvider
MyDomain.Infrastructure.Impl.XmlFileBased.XmlSomeProvider // etc...
MyDomain.Infrastructure.Impl.NHibernate.NHibernateSomeProvider // etc...

Im zweiten Fall ist es klar, welche Implementierung ich irgendwo in meinem Code durch den Klassennamen selbst verwende, aber es scheint ein bisschen überflüssig, sie nach Namespace zu gruppieren und dann in den Klassennamen sowieso, nicht?

Eine dritte Option könnte sein:

MyDomain.Infrastructure.ISomeProvider
MyDomain.Infrastructure.Impl.MemoryBasedSomeProvider
MyDomain.Infrastructure.Impl.MemoryBasedSomeOtherProvider
MyDomain.Infrastructure.Impl.MemoryBasedYetAnotherProvider
MyDomain.Infrastructure.Impl.XmlSomeProvider // etc...
MyDomain.Infrastructure.Impl.NHibernateSomeProvider // etc...

Ich habe die überflüssigen Namespaces eliminiert, aber jetzt ist die einzige Möglichkeit, die Klassen zu gruppieren / zu organisieren, das Präfix des Klassennamens. Ich nehme an, ich könnte sie in Ordner aufteilen und die Namensräume in allen neu erstellten Dateien manuell anpassen. Gibt es klare Vorteile für einen dieser Stile gegenüber den anderen?

Answer 1

Gute Frage. Ich beantworte sie mit einer anderen: Wie wahrscheinlich ist es, dass jemand mehrere Implementierungen von ISomeProvider zu einem bestimmten Zeitpunkt? Wenn dies der Fall ist, wird die Disambiguierung durch den Namespace dazu führen, dass einige unangenehme vollqualifizierte Namespaces benötigt werden.

Wenn nicht, würde ich den Namensraum verwenden, um die Art der Implementierung anzugeben, aber überall dieselben Namen verwenden. So oder so, die Tatsache, dass Ihre API durch Schnittstellen und nicht durch konkrete Implementierungen definiert ist, bedeutet, dass Menschen die Implementierung sehr leicht austauschen können, egal für welche Option Sie sich entscheiden.

Answer 2

Option 1

MyDomain.Infrastructure.Impl.MemoryBased.SomeProvider
MyDomain.Infrastructure.Impl.MemoryBased.SomeOtherProvider
MyDomain.Infrastructure.Impl.MemoryBased.YetAnotherProvider
MyDomain.Infrastructure.Impl.XmlFileBased.SomeProvider // etc...
MyDomain.Infrastructure.Impl.NHibernate.SomeProvider // etc...

Das wäre meine bevorzugte Option. Man könnte argumentieren, dass Sie sie in verschiedenen Projekten pro Implementierung (In-Memory, ORM, XML) haben sollten und dann die erforderliche Implementierung zur Laufzeit geladen werden könnte, je nach Ihrem IoC-Container und Anforderungen zum Zeitpunkt.

Das Herumspielen mit Namespaces und das Hinzufügen des Implementierungstyps in den Namen der Klasse ist übertrieben und lässt Ihre Namespaces für externe/andere Entwickler sinnlos erscheinen.