DLL um Schnittstellenparameter zu sparen

[bernhard_LA]

ich stehe vor folgendem Problem:

Ich habe eine Klasse die vereinfacht 2 Funktion ausführt:

• A. Datenladen und etwas berechnen ( Zeitintensiv) und dann
• B. wenn die Berechnungen durch sind : Werte zurückgeben (geht schnell) .

Der Schritt B. erfolgt an ganz unterschiedlichen Stellen in meiner Anwendung. Schritt A möchte ich irgendwohin verlagern wo mich dieser Zeit nicht stört ( z.b. Programm-Start) Ich möchte diese Klasse aber nicht als weiteren Schnittstellen Parameter über eine ganze Reihe von Funktion hinweg mitschleppen müssen.

Delphi-Quellcode:

     type MyClass = Class
          ....
          FData  :  TMyData;
          .... 
          function TakeLongCalculationTime ( ......)

          function ReadValuefromMYData (aParam) : TAnydata;


          property GiveMeInfo : TAnydata   read ReadValuefromMYData;
          end;

Ist es eine gute Idee die Klasse und Ihre Berechnungen in eine DLL auszulagern und dann von hier die Werte auszulesen wenn ich Sie benötige ,
oder wäre eine globale Variable der sauberere Ansatz ?

[Uwe Raabe]

Zitat von bernhard_LA:

Ist es eine gute Idee die Klasse und Ihre Berechnungen in eine DLL auszulagern und dann von hier die Werte auszulesen wenn ich Sie benötige ,
oder wäre eine globale Variable der sauberere Ansatz ?

Die Idee mit der DLL finde ich etwas abstrus - abgesehen davon, daß sie dein Problem nicht löst, sondern allenfalls neue schafft. Eine globale Variable als Inkarnation eines Singleton ist sicher eine Option. Alle anderen Singleton-Implementierungen kapseln im Endeffekt auch nur so etwas wie eine globale Variable. Eventuell kann man hier aber zeitgemäßer mit Klassenmethoden arbeiten.

[himitsu]

Du willst diese Klasse in eine DLL auslagern, nur um keine globale Instanz davon zu haben?

Damit wäre dann aber die DLL deine globale Instanz-Variable, was am ende auf's Selbe hinauskommt.

Und du könntest diese Klasse im Notfall dann auch nicht mehr mehrmals erstellen, solltest du mal mehrere Instanzen benötigen.



Also ich würde da bei der globalen Vairable bleiben, oder eine Funktion, welche dir Singleton erstellt/liefert.
Wenn du das in eine DLL auslagerst, dann darfst du auch nicht vergessen mindestens den Arbeitsspeicher zu Sharen und du kannst solltest gleich mal vergessen, daß dir die DLL-Funktionen eine Klasse (TAnydata) zurückgeben. (sowas solltest du dann besser auf ein Interface umbauen)

[mjustin]

Zitat von bernhard_LA:

Ich möchte diese Klasse aber nicht als weiteren Schnittstellen Parameter über eine ganze Reihe von Funktion hinweg mitschleppen müssen.

Sind die weiteren Funktionen auch in einer Klasse gekapselt (nennen wir sie KlasseB)? In diesem Fall kann die Übergabe der ersten Klasse in Parametern auch ersetzt werden durch Verwendung einer Property, die beim (oder nach dem) Erzeugen von KlasseB zugewiesen wird.

Dann können die Implementierung der Funktionen (Methoden) in KlasseB auf diese Property zugreifen.

[Furtbichler]

Wozu gibt es eigentlich Datenmodule? Die sind ja nicht nur dazu da, um Queries etc. vorzuhalten, sondern in dem Programmierparadigma 'Datenmodul' sind es eben die Container, die einen davon abhalten sollen, die ganzen Datenmengen ständig hin und her zu schieben. Früher war das mal eine Performancebremse, heute mindestens eine Spaßbremse.

Gut, das Paradigma ist ca. 40 Jahre alt, aber Delphi ist ja nun mal per se 'old school' (was jetzt nicht negativ zu bewerten sein soll, sondern eher als 'altbewährt' zu verstehen ist).

Also: Ein Datenmodul als allgemeinen Datencontainer instantiieren und als eine Eigenschaft dieses Containers eben deine Klasse mit den Daten.

Wenn später noch mehr dazukommen soll, hat man nun schon einen Container, und das Ganze ist aufgeräumt.

Alternativ kannst Du dir auch eine Klasse bauen, die die fertigen Daten kapselt. Bei Bedarf instantiierst Du dir eine Instanz, die dir dann den Zugriff auf diese Daten ermöglicht. Natürlich ist im Hintergrund eine statische Instanz deiner eigentlichen Datenklasse am werkeln, aber nach außen hin eben nicht. Und deshalb ist das auch weder ein Singleton noch eine globale Variable, also auch nicht für OOP-Modernisten 'böse'.

Delphi-Quellcode:

Type
  TMyDataAccess = class
    private class var Data : TMyData;
  public
    Class Procedure Initialize;
    Function GiveMeData() : TAnyData;
  End;

Implementation

class Procedure TMyDataAccess.Initialize;
Begin
  Data := TMyData.Create;
  Data.TakeLongCalculationTime();
End;

Function TMyDataAccess.GiveMeData : TAnyData;
Begin
  Result := Data.GiveMeData;
End;
...
// Beim Programmstart (oder im initialization-Abschnitt der Unit)

TMyDataAccess.Initialize;
...
// Verwendung

... dataAccess := TMyDataAccess.Create;
    Try
      DoSomethingWith(dataAccess.GiveMeData);
    finally
      dataAccess.Free; // Oder für die Hasenfüße: FreeAndNil (dataAccess);
    End;
...

[bernhard_LA]

ich habe noch eine Randbedingung : ich will am existierenden Code möglichst wenig ändern

Gibt es in DELPHI Static Datentypen ? (siehe VB Beispiel)

Delphi-Quellcode:

    Function updateTotalSales(ByVal thisNewSale As Decimal) As Decimal
    Static totalSales As Decimal = 0
    totalSales += thisNewSale
    Return totalSales
    End Function

[Namenloser]

Zitat von bernhard_LA:

Gibt es in DELPHI Static Datentypen ? (siehe VB Beispiel)

Nein, und ich würde sagen zum Glück.

[himitsu]

Was sind Static-DataTypes?


Nunja, typisierte Konstanten, auch Lokale, sind sowas, wenn STATIC das ist, was ich denke.

ABER, es ist nicht unbedingt ein guter Stil, wenn man den Schreibschutz von Konstanten deaktivert.

[Namenloser]

Beschreibbare Konstanten sind für mich ein Hack. Da fällt mir noch ein weiterer ein:

Delphi-Quellcode:

procedure Foo;
type
  TDummyClass = class
    class var StaticVar: integer;
  end;
begin
  TDummyClass.StaticVar := TDummyClass.StaticVar + 1;
end;

Aber bitte sowas nicht tun.

[Furtbichler]

Private statische Variablen sind nicht-lokal beschreibbar? Das wäre ja ein Graus. Wenn nicht, ist deine Anmerkung überflüssig, denn lokale Variablen/private Felder sind immer beschreibbar.

Aber Ich denke, Du verwechselst 'static' mit 'const', es gilt aber 'static' = 'class var'. Und 'var' steht nicht für 'konstant'. Und auch nicht für 'varscheinlich konstant'


Eine statische (Class-) Variable ist übrigens eine Variable, die nicht der Instanz zugeordnet ist, sondern der Klasse. Also sowas wie (globale) Variablen.

Delphi-Quellcode:

Type
  TStaticClass = class
    private class Var hidden : TSomeType;
    public class Var known : TSomeType;
  end;

// Entspricht von der Sichtbarkeit

Unit TStaticUnit;
Interface
Var
  known : TSomeType;
Implementation
  hidden : TSomeType;
End.

Old school würde man eine Read-Only Variable (was hier noch besser wäre, aber dann bräuchte man einen statischen Konstruktor) als Funktion (z.B. Printer, Clipboard) umsetzen;

Delphi-Quellcode:

Unit Stuff;
interface
  function DataAccess : TSomeType;
implementation
Var
  _dataAccess : TSomeType;

Function DataAccess : TSomeType;
Begin
  Result := _dataAccess;
End;

// Oder mit Lazy load
Function DataAccess : TSomeType;
Begin
  if _dataAccess = nil then _dataAccess := CreateDataAccess;
  Result := _dataAccess;
End;