ClassFactory ähnlich wie Spring Framework, Hilfe gesucht!

[Stevie]

Zitat:

Zitat von Der schöne Günther (Beitrag 1247051)

Klassendefinitionen als Ersatz für "protected/package/... class" in den implementation-Teil zu schieben handhabe ich teilweise auch noch so. Habt Ihr die Diskussion öffentlich geführt? Rein interessenshalber.

Teilweise, ich hab ihn bei jeder Gelegenheit (comments in posts, Review seines Buches und als wir uns auf der EKON17 trafen) darauf aufmerksam gemacht.
Wir beide betrachten DI und "coding against abstractions" nicht als Selbstzweck, sondern als Mittel zu entkoppeltem und damit isoliert testbarem Source.
Und das erreicht man nicht, wenn man die eine offensichtliche Kopplung - nämlich die Benutzung einer konkreten Implementierung (Klasse) statt einer Abstraktion (Interface oder abstrakte Klasse) - durch eine andere - nämlich die Kopplung auf den Container - ersetzt.

Wenn ich also meine TMySampleClass nicht mehr in einem Projekt benutzen kann, ohne den Container auch zu benutzen (da er ja fest in der Unit verdrahtet ist), dann läuft was falsch.

P.S. :mrgreen:

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1247045)

@Mavarik
Das Verstecken von Klassen im Implementation Teil, damit sie ja keiner so nutzt, ist Unfug, wenn man sie dann über ein Interface von hintenrum verfügbar macht. Denn das ist der Tod für jegliche Testbarkeit der Klasse und dann fangen einige an, mit Compiler switches und weiß der Teufel das ganze für Unittests sichtbar zu machen. Außerdem ist das garantiert kein Design Pattern sondern eine Delphi Eigenheit.

Stimmt auch wieder, nur weil ich die Definition in den Interface Teil hole, bedeutet ja nicht, dass ich es - außer für Tests - auch benutzen muss.

Ich finde es einfach praktisch, nicht eine Uses Zeile mit 30 Units zu haben, sondern nur eine für den Container.

Es hat sich mir auch nicht erschlossen, warum ich die Implementierung des Interfaces nicht in der gleichen Unit machen soll.

Mavarik

[Stevie]

Zitat:

Zitat von Mavarik (Beitrag 1247068)

Es hat sich mir auch nicht erschlossen, warum ich die Implementierung des Interfaces nicht in der gleichen Unit machen soll.

Das erschließt sich meist erst, wenn man eine größere bzw "richtige" Anwendung hat. In dem Fall ein Interface, eine Klasse mag es erstmal unnötige Arbeit sein, das in eigene Unit zu packen, aber wenn diese dann von anderen Teilen benutzt merkt man, dass man bei einer Trennung dort tatsächlich nur eine Abhängigkeit auf die Abstraktion (Interface) hat und sich auch nicht von hinten rum, die Implementierung rein holt (weil sie in derselben Unit wie das Interface ist). Wenn man mehrere Implementierungen für ein Interface hat, fällt es direkt auf. Und wenn man dann einen Unittest für Klasse A schreibt, die Interface B benutzt, was man nur ausmocken muss, aber trotzdem Klasse B im Test drin ist, auch.

Man merkt sowas immer schnell, wenn man mal kurz eine kleine Testapplikation schreibt, welche ein

Delphi-Quellcode:

TToaster

testen will. Und plötzlich wundert man sich, dass in die Anwendung auch

Delphi-Quellcode:

TStadtwerke

,

Delphi-Quellcode:

TUmspannwerk

,

Delphi-Quellcode:

TKraftwerk

und

Delphi-Quellcode:

TBraunkohletagebau

einkompiliert werden, nur weil man den

Delphi-Quellcode:

TToaster

an den Strom anschließen kann. :)

Ich stimme dir aber zu, wenn man das so praktiziert, kann das zu langen uses Klauseln kommen, dahingehend hat man es in Java oder C# einfacher mit richtigem Namespacing (so nach dem Motto

Delphi-Quellcode:

uses MyLib.*;

statt

Delphi-Quellcode:

uses MyLib.Foo, MyLib.Bar, MyLib.MoreStuff, ...;

).

[Uwe Raabe]

Zitat:

Zitat von Stevie (Beitrag 1247073)

Ich stimme dir aber zu, wenn man das so praktiziert, kann das zu langen uses Klauseln kommen, dahingehend hat man es in Java oder C# einfacher mit richtigem Namespacing (so nach dem Motto

Delphi-Quellcode:

uses MyLib.*;

statt

Delphi-Quellcode:

uses MyLib.Foo, MyLib.Bar, MyLib.MoreStuff, ...;

).

Dieses Feature birgt aber wiederum andere Gefahren: Damit würden ja alle Units dieses NameSpace (MyLib) eingebunden die im Suchpfad gefunden werden. Das wäre mit den aktuellen Units von Delphi XE5 schon mal nicht praktikabel, da dort z.B. plattformabhängige Units gleichnamige Methoden deklarieren (bei FMX z.B. FMX.Controls.<Android|iOS|Mac|Win>). Bei einem NameSpace FireDAC.* hätte man plötzlich alle verfügbaren Datenbanktreiber mit eingebunden, was in den seltensten Fällen wirklich erwünscht ist. Für selbstgestrickte Units kann man da sicher Vorkehrungen treffen, aber dann müssen die NameSpaces und Unitnamen auch gut überlegt sein.

[TiGü]

Zitat:

Zitat von Mavarik (Beitrag 1247068)

Ich finde es einfach praktisch, nicht eine Uses Zeile mit 30 Units zu haben, sondern nur eine für den Container.

Ok, schauen wir mal:

15 Interface-Units + 15 Class-Units (+ Container-Unit) in der Uses-Sektion der Register-Unit.
Alles übersichtlich auf einen Blick, die Interfaces und Classes wissen nichts von den DI-Kram.

oder

In den 15 Class-Units die Container-Unit inkludieren.
Bisschen weniger in der Uses-Sektion, aber man halt wieder diese Abhängigkeit.

[Der schöne Günther]

Meine persönliche Meinung auch:

Echte Namespaces würden Delphi sicher gut tun, aber viel zu häufig sehe ich in anderen Sprache Leute mit allem möglichen immer

Delphi-Quellcode:

.*

includen. In Delphi ist das sicher noch stärker ein Problem da ich (zumindest in der RTL und VCL) oft richtig viel Code in den initialization/finalization-Blöcken sehe und der Linker die (eigentlich unbenutzten) Sachen nicht wieder entfernt.

Ich bin sogar eher ein Freund von vielen Units in der uses-Clause. Man kann allein daran schon irgendwie sehen, was los ist. Genauso ist der eigene var-Block in Methoden etwas, das ich an Pascal wirklich lieben gelernt habe. In anderen Sprachen fehlt mir das.

Aber wir kommen irgendwie auch vom Thema ab 8-)

[Stevie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1247083)

Dieses Feature birgt aber wiederum andere Gefahren: Damit würden ja alle Units dieses NameSpace (MyLib) eingebunden die im Suchpfad gefunden werden. Das wäre mit den aktuellen Units von Delphi XE5 schon mal nicht praktikabel, da dort z.B. plattformabhängige Units gleichnamige Methoden deklarieren (bei FMX z.B. FMX.Controls.<Android|iOS|Mac|Win>). Bei einem NameSpace FireDAC.* hätte man plötzlich alle verfügbaren Datenbanktreiber mit eingebunden, was in den seltensten Fällen wirklich erwünscht ist. Für selbstgestrickte Units kann man da sicher Vorkehrungen treffen, aber dann müssen die NameSpaces und Unitnamen auch gut überlegt sein.

Ich wär ja schon glücklich, wenn man generische Typen redeklarieren könnte, dann könnte man sich so pseudo Namespace Units bauen, wo man Dinge aus anderen Units zusammenführen kann.

[Furtbichler]

Zitat:

Zitat von Stevie (Beitrag 1247045)

Das Verstecken von Klassen im Implementation Teil, damit sie ja keiner so nutzt, ist Unfug, wenn man sie dann über ein Interface von hintenrum verfügbar macht.

Gibt es denn andere Möglichkeiten, in Delphi die Sichtbarkeit von Klassen zu regeln?

Beispiel:Ich definiere im interface nur den Getter, aber die Klasse hat 'intern' auch einen Setter, weil das nunmal für die Implementierung des Subsystems notwendig ist. Nur die Anwender (also die, die nur das Interface sehen) sollen nur den Getter sehen bzw. benutzen dürfen.

Ich bin schon ne Weile nicht mehr so in Delphi drin, daher ist die Frage bestimmt ein wenig blöd. Welche Frage eigentlich? Ach, ja: s.o. ;-)

[Der schöne Günther]

Die Frage hat doch mit dem Beispiel nichts zu tun?

Das (public|<nichts>) in Java bzw. (public|internal) in C# für Typen gibt es in Delphi schlichtweg nicht. Sichtbarkeit halt nur entweder "Alle" oder "Nur diese Unit" - Je nachdem ob die Deklaration im Interface- oder Implentation-Teil stattfindet.

Namespaces bzw. Packages gibt es grundsätzlich nicht, deshalb erübrigt sich dann auch der Gedanke, bsp. den Setter nur im Package und nicht außerhalb verfügbar zu machen.

Die Delphi-Dokumentation nennt es gerne Namespaces, aber das ist schlichtweg nicht wahr. Es sind einfach nur Prefixe im Unit-Namen.

[Stevie]

Wenn ich richtig informiert bin, macht man aber auch in C# solche Klassen, über die wir hier sprechen nicht internal sondern public, auch wenn man sie direkt nicht benutzt bzw instanziiert.

Denn auch dort schreibt man DI Container Code ja nicht direkt in diesen Namespace sondern hat einen extra Codebereich dafür (oder machts über XML).

Womit wir wieder beim gleichen "Problem" wären. Man versteckt die Klassen ja nicht, damit irgendein unwissender Entwickler sie nicht aus Versehen benutzt.