ClassFactory ähnlich wie Spring Framework, Hilfe gesucht!

[Mavarik]

Hallo Zusammen!

Ich möchte in einer GlobalenListe einen Bezug vom Interface zu Klasse herstellen.

Delphi-Quellcode:

Unit MyFooImp;

Interface
Implementation

Uses MyContainer,MyInterfaces; // Defionition von IFoo

Type 
    TFoo = class(TInheritedObject,iFoo);
      Procedure bla; // bla bla
    end;

Initialization
  GlobalContainer.Registerclass<IFoo,TFoo>; // Dictionary
end.

Um dann an einer anderen Stelle:

Delphi-Quellcode:

Procedure DoFoo;
var
  Foo : IFoo;
begin
  Foo := GlobalContainer.GetClass<IFoo>;  // Result unterschiedlich IFoo & TObject
  Foo.Bla;
end;

Bei der Formfactory war das irgentwie kein Problem mit der Class of TForm, aber hier bekomme ich es einfach nicht hin, aus GlobalContainer.GetClass<IFoo> logisch TFoo.Create zu machen.

Hat jemand ne Idee?

[mkinzler]

Dann wäre doch DSPING etwas für dich, bzw. kannst du dort nachschauen, wie das dort gelöst wird.

[Mavarik]

Zitat:

Zitat von mkinzler (Beitrag 1246948)

Dann wäre doch DSPING etwas für dich, bzw. kannst du dort nachschauen, wie das dort gelöst wird.

:oops: emm :roll: tja :stupid: kapiere es leider nicht was die da machen :gruebel:

[mkinzler]

http://code.google.com/p/delphi-spring-framework/

[Sir Rufo]

Damit geht das

Delphi-Quellcode:

unit Container;

interface

uses
  System.Generics.Collections;

type
  GlobalContainer = class
  private
    class var _ClassDict : TDictionary<TGUID, TClass>;
  protected
    class constructor Create;
    class destructor Destroy;
  public
    class procedure RegisterClass<TInterface : IInterface; TRegClass : class>;
    class function GetClass<T : IInterface> : T;
  end;

implementation

uses
  System.SysUtils,
  System.TypInfo;

{ GlobalContainer }

class constructor GlobalContainer.Create;
begin
  _ClassDict := TDictionary<TGUID, TClass>.Create;
end;

class destructor GlobalContainer.Destroy;
begin
  _ClassDict.Free;
end;

class function GlobalContainer.GetClass<T> : T;
var
  LGUID : TGUID;
  LClass : TClass;
  LObj : TObject;
begin
  LGUID := GetTypeData( TypeInfo( T ) ).Guid;
  if _ClassDict.ContainsKey( LGUID ) then
  begin
    LClass := _ClassDict.Items[LGUID];
    LObj := LClass.Create;
    Supports( LObj, LGUID, Result );
  end;
end;

class procedure GlobalContainer.RegisterClass<TInterface, TRegClass>;
var
  LGUID : TGUID;
begin
  LGUID := GetTypeData( TypeInfo( TInterface ) ).Guid;
  _ClassDict.AddOrSetValue( LGUID, TRegClass );
end;

end.

[Sir Rufo]

Wenn man auch noch das hier

Delphi-Quellcode:

type
  IFoo = interface
    ['{4C53C006-737E-4F3C-A424-D5A34335EC0C}']
    procedure Bar;
  end;

  TFoo = class( TInterfacedObject, IFoo )
  private
    procedure Bar;
  end;

  TAnotherFoo = class( TFoo )
  private
    procedure Bar;
  end;

  { TFoo }

procedure TFoo.Bar;
begin
  Writeln( Self.ClassName + '.Bar' );
end;

{ TAnotherFoo }

procedure TAnotherFoo.Bar;
begin
  Writeln( Self.ClassName + '.Bar' );
end;

procedure Test;
var
  LFoo : IFoo;
begin
  GlobalContainer.RegisterClass<IFoo, TFoo>;
  GlobalContainer.RegisterClass<IFoo, TAnotherFoo>( 'Another' );
  LFoo := GlobalContainer.GetClass<IFoo>;
  LFoo.Bar; // -> TFoo.Bar
  LFoo := GlobalContainer.GetClass<IFoo>( 'Another' );
  LFoo.Bar; // -> TAnotherFoo.Bar
end;

abgetütet haben will, dann so

Delphi-Quellcode:

unit Container;

interface

uses
  System.SysUtils,
  System.Generics.Collections;

type
  EContainerException = class( Exception );

  GlobalContainer = class
  private
    class var _ClassDict : TDictionary<string, TClass>;
  protected
    class constructor Create;
    class destructor Destroy;
  public
    class procedure RegisterClass<TInterface : IInterface; TRegClass : class>( const Name : string = '' );
    class function GetClass<T : IInterface>( const Name : string = '' ) : T;
  end;

implementation

uses
  System.TypInfo;

{ GlobalContainer }

class constructor GlobalContainer.Create;
begin
  _ClassDict := TDictionary<string, TClass>.Create;
end;

class destructor GlobalContainer.Destroy;
begin
  _ClassDict.Free;
end;

class function GlobalContainer.GetClass<T>( const Name : string ) : T;
var
  LGUID : TGUID;
  LKey : string;
  LClass : TClass;
  LObj : TObject;
begin
  LGUID := GetTypeData( TypeInfo( T ) ).Guid;
  LKey := LGUID.ToString + Name.ToUpper;
  if _ClassDict.ContainsKey( LKey ) then
  begin
    LClass := _ClassDict.Items[LKey];
    LObj := LClass.Create;
    Supports( LObj, LGUID, Result );
  end
  else
    raise EContainerException.CreateFmt( 'Keine Klasse zum Interface%s(%s) gefunden', [LGUID.ToString, Name] );
end;

class procedure GlobalContainer.RegisterClass<TInterface, TRegClass>( const Name : string );
var
  LGUID : TGUID;
  LKey : string;
begin
  LGUID := GetTypeData( TypeInfo( TInterface ) ).Guid;
  LKey := LGUID.ToString + Name.ToUpper;
  _ClassDict.AddOrSetValue( LKey, TRegClass );
end;

end.

[Mavarik]

Zitat:

Zitat von Sir Rufo (Beitrag 1246952)

Delphi-Quellcode:

if _ClassDict.ContainsKey( LGUID ) then
  begin
    LClass := _ClassDict.Items[LGUID];
    LObj := LClass.Create;
    Supports( LObj, LGUID, Result ); // <-- das fehlte mir einfach...
  end;

Oh man... Yes Sir! Darauf muss man kommen? Du bist echt der DUKE... Vielen Dank...:thumb:

Musste noch meinen GlobalContainer umbauen, das war auch ein Interface und da wollte Generics nicht.

Mavarik

[Sir Rufo]

Zitat:

Zitat von Mavarik (Beitrag 1246956)

Zitat:

Zitat von Sir Rufo (Beitrag 1246952)

Delphi-Quellcode:

if _ClassDict.ContainsKey( LGUID ) then
  begin
    LClass := _ClassDict.Items[LGUID];
    LObj := LClass.Create;
    Supports( LObj, LGUID, Result );
  end;

Oh man... Yes Sir! Darauf muss man kommen? Du bist echt der DUKE... Vielen Dank...:thumb:

Musste noch meinen GlobalContainer umbauen, das war auch ein Interface und da wollte Generics nicht.

Mavarik

Büdde, büdde

Es fehlt allerdings bei der Registrierung die Prüfung, ob die Klasse das Interface unterstützt.
Aber war auch nur auf die Schnelle ;)

[Mavarik]

Zitat:

Zitat von Sir Rufo (Beitrag 1246957)

Es fehlt allerdings bei der Registrierung die Prüfung, ob die Klasse das Interface unterstützt.
Aber war auch nur auf die Schnelle ;)

Nicht so?

Delphi-Quellcode:

if _ClassDict.ContainsKey( LGUID ) then
  begin
    LClass := _ClassDict.Items[LGUID];
    LObj := LClass.Create;
    if not(Supports( LObj, LGUID, Result )) then
      raise EContainerException.CreateFmt( 'Keine Klasse zum Interface%s(%s) gefunden', [LGUID.ToString, Name] );    
  end;

Mavarik

[Stevie]

Zitat:

Zitat von Sir Rufo (Beitrag 1246952)

Damit geht das

Delphi-Quellcode:

class function GlobalContainer.GetClass<T> : T;
var
  LGUID : TGUID;
  LClass : TClass;
  LObj : TObject;
begin
  LGUID := GetTypeData( TypeInfo( T ) ).Guid;
  if _ClassDict.ContainsKey( LGUID ) then
  begin
    LClass := _ClassDict.Items[LGUID];
    LObj := LClass.Create;
    Supports( LObj, LGUID, Result );
  end;
end;

Leider geht das so nicht. Deshalb gibt es in Spring4d auch relativ komplexe Logik, um den "best matching" Konstruktor zu finden.
Es ist nämlich nicht immer richtig den Parameterlosen Standardkonstruktor aufzurufen, da er eigentlich versteckt wurde (z.B. bei TComponent)
Über deine Logik würde zwar der richtige Speicher allokiert aber niemals die ganzen Dinge aus dem

Delphi-Quellcode:

Create(AOwner: TComponent)

durchlaufen. Auch Spring4d ist nicht komplett wasserdicht, da die RTTI keine Möglichkeit bietet zu ermitteln, ob eine Methode überschrieben oder verdeckt wurde. Auch der constructor Constraint bei generics leidet unter dieser Macke, so dass ein

Delphi-Quellcode:

T.Create

ziemlich böse Folgen haben kann.

Aktueller Source von Spring4d liegt übrigens hier: https://bitbucket.org/sglienke/spring4d (das Google Code Repo wird nicht mehr aktualisiert)

Mein Vorschlag wäre übrigens, nicht Interface/Klasse als Kombination zu registrieren, sondern Interface/Factory.

Somit würde aus deinem Dictionary ein

Delphi-Quellcode:

TDictionary<string, TFunc<IInterface>>

.

Die RegisterClass Methode würd ich dann so schreiben (nicht Compiler checked):

Delphi-Quellcode:

class procedure GlobalContainer.RegisterClass<TInterface: IInterface, TRegClass: class, constructor>( const Name : string );
var
  LGUID : TGUID;
  LKey : string;
begin
  // hier aufpassen, kann auch keine guid haben, dann sollte man hier einen Fehler werfen, denn das resolven wird nicht ohne funktionieren
  // ebenfalls sollte man checken, ob die Klasse, das Interface überhaupt supported
  LGUID := GetTypeData( TypeInfo( TInterface ) ).Guid; 
  LKey := LGUID.ToString + Name.ToUpper;
  _ClassDict.AddOrSetValue( LKey, 
    function: IInterface 
    var
      obj: TObject;
    begin 
      // wie gesagt, hier aufpassen, kann sein, dass das den falschen Konstruktor aufruft, das fängt auch der constructor Contraint nicht korrekt ab
      obj := TRegClass.Create; 
      // kein if notwendig, wenn oben geschaut wurde, ob das hier auch funktioniert
      Supports(obj, LGUID, Result);
    end);
end;

Das hat nun den Vorteil, dass du auch eine

Delphi-Quellcode:

RegisterClass<IMyIntf>(function: IMyIntf begin Result := GetMyIntfFromSomewhere() end)

schreiben kannst und nicht nur auf Zuordnung von Interface zu Klasse beschränkt bist.

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1246960)

Leider geht das so nicht. Deshalb gibt es in Spring4d auch relativ komplexe Logik, um den "best matching" Konstruktor zu finden.

Dein Einwand bezieht sich aber "nur" auf Konstruktoren die Parameter haben, oder?

Der Einfache TFoo.Create; macht doch keine Probleme...

Mavarik

[Stevie]

Zitat:

Zitat von Mavarik (Beitrag 1246961)

Zitat:

Zitat von Stevie (Beitrag 1246960)

Leider geht das so nicht. Deshalb gibt es in Spring4d auch relativ komplexe Logik, um den "best matching" Konstruktor zu finden.

Dein Einwand bezieht sich aber "nur" auf Konstruktoren die Parameter haben, oder?

Der Einfache TFoo.Create; macht doch keine Probleme...

Mavarik

Ja, aber da du im Eingangspost erwähnt hast, dass es für TForm ginge, hab ich das geschrieben. Denn obwohl der Source kompiliert und auch TForm.Create aufgerufen wird (was ja nicht gehen dürfte, denn der ist durch den TComponent Konstruktor nunmal verdeckt), wird das Form ziemlich vor die Wand semmeln, da alles, was so in den Konstruktoren ab TComponent gemacht wird, nicht ausgeführt wird.

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1246966)

Ja, aber da du im Eingangspost erwähnt hast, dass es für TForm ginge,

Nein! Geht mir um normale Klassen für TForms habe ich schon ein Formfactory programmiert.

Mavarik

[Stevie]

Noch'n Tip: Lagere das Register in eine extra Unit aus und mach das nicht im initialization Part der Unit mit der Klasse.
Dadurch erreichst du nämlich keineswegs eine Entkopplung sondern nur 1. Untestbarkeit deiner Klasse (dadurch, dass sie im Implementation Teil deiner Unit versteckt ist) und 2. indirekte Kopplung deiner Klasse auf den Container (dadurch, dass die Container Unit im Uses deiner Klassen Unit steht).

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1246971)

Noch'n Tip: Lagere das Register in eine extra Unit aus und mach das nicht im initialization Part der Unit mit der Klasse.
Dadurch erreichst du nämlich keineswegs eine Entkopplung sondern nur 1. Untestbarkeit deiner Klasse (dadurch, dass sie im Implementation Teil deiner Unit versteckt ist) und 2. indirekte Kopplung deiner Klasse auf den Container (dadurch, dass die Container Unit im Uses deiner Klassen Unit steht).

Sehe ich anders. Im InitPart ist es schön! Da ja auch die Klasse in der Unit definiert ist. Die Referenz zum Container stört mich nicht. Wie soll ich den das in einer anderen Unit machen? Aus einer anderen Unit komme ich doch nicht an die Klasse ran!

Mavarik

[Union]

Stevie hat aber Recht mit der Entkopplung. Das hatten wir gestern schon mal. Genau wie Supports ;)

[TiGü]

Zitat:

Zitat von Mavarik (Beitrag 1246997)

Wie soll ich den das in einer anderen Unit machen? Aus einer anderen Unit komme ich doch nicht an die Klasse ran!

Ganz einfach!

Delphi-Quellcode:

unit MyInterfaces;

interface

const
  SID_Sample      : string = '{13B2116B-B78B-4E89-8070-83F9E36720EF}';
  SID_OtherSample : string = '{74EF1A68-1EED-4DA4-9845-5F77AEB6D2DA}';

type
  ISample = interface(IUnknown)
  [SID_Sample]
    procedure Foo;
    function Bar : Boolean;
  end;

  IOtherSample = interface(IUnknown)
  [SID_OtherSample]
    procedure FooFoo;
    function BarHocker : Boolean;
  end;

implementation

end.

Den Spaß werden wir hier implementieren:

Delphi-Quellcode:

unit MyClasses;

interface

uses
  MyInterfaces;

type
  TMySampleClass = class(TInterfacedObject, ISample)
  private
    function Bar: Boolean;
    procedure Foo;
  end;

  TMyOtherSampleClass = class(TMySampleClass, IOtherSample)
  private
    function BarHocker: Boolean;
    procedure FooFoo;
  end;

implementation

{blablabla - Methoden über Methoden}

end.

Die Unit Container ist ja jedem hier bekannt; so melden wir alle schön an:

Delphi-Quellcode:

unit RegisterMyClasses;

interface

implementation

uses
  Container, MyInterfaces, MyClasses;

initialization
  Container.GlobalContainer.RegisterClass<ISample, TMySampleClass>;
  Container.GlobalContainer.RegisterClass<IOtherSample, TMyOtherSampleClass>;

end.

Tataaaa! :party:

[Mavarik]

Wie war noch das Design-Pattern!

Niemals Klassendefinitionen im Interface Teil. Sonst Referenziert man noch dagegen?

Mavarik

[Stevie]

@Mavarik
Den Zahn hab ich Nick Hodges schon lange gezogen, der das ne Weile gepredigt hat - aus genau den oben genannten Gründen.
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.

Außerdem sollte man seinen Code so schreiben, dass er auch ohne einen DI Container durch manuelles Zusammenstecken funktionieren würde. Und das ist hier auch nicht der Fall.

@TiGü
:thumb:

[Der schöne Günther]

Ich habe den Thread noch nicht gelesen und mir für's Wochenende aufgehoben.

Weniger zu Spring (für deine unermüdliche Arbeit an Spring4D stelle ich in meinem Garten irgendwann mal eine Statur mit Lorbeerkranz von dir auf), sondern zu Klassen-Sichtbarkeit:

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.

[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.

[Furtbichler]

Zitat:

Zitat von Stevie (Beitrag 1247217)

Man versteckt die Klassen ja nicht, damit irgendein unwissender Entwickler sie nicht aus Versehen benutzt.

Wir verstecken Klassen, damit man sie nicht einfach unkontrolliert instantiiert, sondern geregelt über eine Factorymethode. Das Problem ist, das manchmal virtuelle Initialisierungsroutinen aufgerufen werden müssen, und das ist im Konstruktor leider problematisch. Unsere Lösung: Interface publizieren, Klasse verstecken, Factorymethode öffentlich machen. Dort findet dann die geregelte Instantiierung und Initialisierung statt.