Factory Pattern - Konstruktoren abschotten

[Peter Enz]

Muss der konkrete Typ des Objekts aus der Factory der Anwendung nicht bekannt sein? Also muss die Anwendung dann die Assembly des konkreten Typs nicht referenzieren?

Nein, das ist ja gerade der Sinn und Zweck des Factory-Patterns, dass die Anwendung die konkrete Implementation nicht sieht, sondern nur Zugriff auf die Interfaces in, wie Ralf schon geschrieben hat, eigenen Assemblies hat.

Und weil die Anwendung den jeweiligen konkreten Typ nicht sieht, erübrigt sich auch die Frage, ob und wie man den Aufruf des Konstrukors aus der Anwendung verhindern kann. Man kann ihn nicht aufrufen, weil der konkrete Typ in der Anwendung unbekannt ist. (Ja ich weiß, per Reflection könnte man, wenn man sich eine Instanz über die Factory beschafft hat, mit dieser dann doch wieder direkt eine zweite erzeugen...)

Gruß
Peter

[fanderlf]

OK mir war nicht ganz bewusst dass es so funktioniert. Allerdings funktioniert es auch nur, wenn das Interface, die Factory und die konkreten Klassen auf jeweils eine Assembly verteilt werden.
Aber das ist ein Mechanismus, den ich auch schon das ein oder andere mal hätte gebrauchen können

Gibt es dann in großen Projekten Assemblies die nur Interfaces beinhalten? Macht man dann pro Layer eine Assembly mit Interfaces oder wie wird das gehandhabt?

[Peter Enz]

Gibt es dann in großen Projekten Assemblies die nur Interfaces beinhalten?

Klar. Naja, eigentlich sollte Software nur noch so gebaut werden.

Macht man dann pro Layer eine Assembly mit Interfaces oder wie wird das gehandhabt?

Nein. Es werden sicherlich mehr Assemblies werden. Wie Du Deine Interfaces in Assemblies verteilst, ist erstmal egal.

Wenn Dich das Thema interessiert, solltest Du mal nach Dependency Injection, Inversion of Control und/oder Software Factories googlen.

U.a. Ralf Westphal beschäftigt sich immer wieder mit dem Thema in seinen verschiedenen Blogs: http://ralfw.blogspot.com.

Oder schau Dich mal bei den Clean Code Developers um:
http://www.clean-code-developer.de/w...ntrolContainer

Und bei Codeplex gibt es mit Unity einen dependency injection container mit ausführlichen Dokus, Hands On Labs und Demos. Irgendwann gab es bei MSDN auch einen Webcast dazu.

Weitere Tools bei http://www.clean-code-developer.de/w...dWerkzeugliste

HTH
Peter

[Ralf Jansen]

Gibt es dann in großen Projekten Assemblies die nur Interfaces beinhalten?

Jein. Eigentlich sollte es so sein aber über ein Interface werden ja üblicherweise auch Daten ausgetauscht Diese könnten ihrerseits natürlich auch wieder nur als Interfaces nach außen geführt sein aber an irgendeiner Stelle muss man ja auch mal die Kirche im Dorf lassen (da ist man dann ganz scharf an der Grenze zum Overengineering). Reine Datenobjekte (oder öffentliche enums etc.) zum Austausch zwischen den Schichten eines Systems gehören auch zum Interface einer Schicht und gehören damit auch in die Interface Assembly dieser Schicht.

Macht man dann pro Layer eine Assembly mit Interfaces oder wie wird das gehandhabt?

Pro Problemsphäre eine Interface Assembly. Assemblies nach technischen Gesichtspunkten aufzuteilen ist der Anfang dann sollte man aber bei den fachlichen Gesichtspunkten weitermachen. Es macht ja keinen Sinn fachlich unabhängige Dinge, nur weil sie zufällig in der selben Schicht stattfinden, zusammen zu werfen.

[Peter Enz]

aber über ein Interface werden ja üblicherweise auch Daten ausgetauscht

Hallo Ralf,

diese Aussage verstehe nicht. Wo und wie werden über ein Interface Daten ausgetauscht?

Gruß
Peter

[Ralf Jansen]

Ich habe mich vermutlich unglücklich ausgedrückt. Ich gehe davon aus das dir klar ist was ich eigentlich meinte
Ein banales Beispiel: Ein Interface für einen Service der irgendwelche Daten liefern soll.

public interface IService
{
     IEnumerable<Data> RetrieveData(SearchCriteria searchCriterias);
}

Data und SearchCriteria sind dabei Klassen die logisch zum Service gehören aber nach außen veröffentlicht sind. Damit gehören sie da sie Teil der Oberfläche des Services sind in die Interface Assembly die diesen Service beschreibt.

P.S. Man könnte natürlich beide Klassen auch wiederum als Interfaces im IService Interface übergeben aber das wird ab einer bestimmten Schachtelungstiefe äußerst unpraktisch. Und wenn Data zum Beispiel ein Enum ist auch eher unmöglich.

[fanderlf]

CCD und Dependency Inversion sind mir schon ein Begriff. Ich hab auch schon viel drüber gelesen, ich bin nur leider hier der einzige auf der Arbeit der sich mit so etwas beschäftigt und sich das alles im Selbststudium neben der eigentlichen Arbeit beizubringen ist schon nicht ganz einfach. Deswegen frag ich hier hin und wieder mal nach wenns interessante Themen wie dieses hier gibt Finde es sehr sehr wichtig strukturiert und organisiert zu programmieren.
Ausserdem sind die Projekte die wir hier haben fast etwas zu klein um so eine Struktur aufzuziehen.

[Peter Enz]

Ich habe mich vermutlich unglücklich ausgedrückt. Ich gehe davon aus das dir klar ist was ich eigentlich meinte

Nö. Denn Du hattest geschrieben, dass über ein Interface Daten ausgetauscht werden und genau das passiert nicht. Erst die Klasse, die das Interface implementiert, ist dazu in der Lage.

In Deinem letzten Post hast Du das ja auch klar gestellt.

Ich sehe auch keine Besonderheit darin, dass Interfaces in Verbindung mit Services ( hier für einen Datenaustausch) verwendet werden. Das ist halt auch ein Einsatzgebiet für Interfaces.

Aber ich denke, da sind wir auf einer Linie.