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:

Zitat von bernhard_LA (Beitrag 1232278)

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:

Zitat von bernhard_LA (Beitrag 1232278)

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:

Zitat von bernhard_LA (Beitrag 1232370)

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' :wall:


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;

[himitsu]

OK, wenn STATIC = Class Var, dann isses schon nicht mehr so böse.

Im Prinzip geht aber auch sowas, aber ich verrate jetzt nicht die beiden Wege (den "offiziellen", der aber nur aus Kompatibilitätsgründen zu extrem alten Delphi-Codes vorhanden ist und den ganz bösen Hack, der mit mal passiert ist, als ausversehn die globale Konstante für einen leeren String

Delphi-Quellcode:

''

zerschossen wurde, was nicht gut endete).

Delphi-Quellcode:

function Test(i: Integer): Integer;
const
  Temp: Integer = 0;
begin
  Inc(Temp, i);
  Result := Temp;
end;

[Namenloser]

Zitat:

Zitat von Furtbichler (Beitrag 1232385)

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' :wall:

Ich weiß, was der Unterschied zwischen static und const ist. Ich bezog mich auf das, was himitsu im vorherigen Beitrag angedeutet hatte. Es ist in Delphi tatsächlich mithilfe eines Compilerswitches möglich, dass typisierte konstanten eben nicht konstant sind, sondern gerade beschreibbar, so wie globale Variablen. Siehe himitsus Beispiel im Post über mir.

Größtes WTF in der ganzen Sprache.

Mein Code ist eigentlich schon eine 1:1-Entsprechung einer „methoden-statischen“ Variable à la PHP & Co. in Delphi. Aber sich extra eine Dummy-Klasse deklarieren, nur damit man eine globale Variable hat, auf die man nur in einer einzigen Routine zugreifen kann, kann irgendwie keine Lösung sein, und deshalb rate ich davon ab.

Ich halte von statischen Variablen in Methoden aber auch generell nichts.

[Furtbichler]

Na, wenn Du ein neues Wort für 'static field', oder 'class var' einführen willst, nämlich 'methoden-statisch'... bitte sehr.

[Uwe Raabe]

Zitat:

Zitat von NamenLozer (Beitrag 1232500)

Es ist in Delphi tatsächlich mithilfe eines Compilerswitches möglich, dass typisierte konstanten eben nicht konstant sind, sondern gerade beschreibbar, so wie globale Variablen. Siehe himitsus Beispiel im Post über mir.

Größtes WTF in der ganzen Sprache.

Den Schalter gibt es nur aus Gründen der Abwärtskompatibilität. Als es in Delphi noch keine initialisierten globalen Variablen gab, waren die veränderbaren Konstanten der einzige Weg sowas zu realisieren. Dieser ominöse Schalter sollte somit auch nur für noch nicht portierten Code Anwendung finden. Allerdings ist dieses Feature, wie so oft, auch schon zu anderen Zwecken missbraucht worden. Um auch zu solchen Code kompatibel zu bleiben, wird es den Schalter wohl noch eine ganze Weile geben.

[Furtbichler]

Zitat:

Zitat von Uwe Raabe (Beitrag 1232503)

Als es in Delphi noch keine initialisierten globalen Variablen gab, waren die veränderbaren Konstanten der einzige Weg sowas zu realisieren.

Öhm...

Delphi-Quellcode:

Var
  global : String;

initialization
  global :='Initialized Value';
end.

So hab ich das immer gemacht.

Schon bei Turbo-Pascal (DOS) waren Konstanten veränderbar. Konstanten wurden nicht als Platzhalter kompiliert (wie z.B. bei C und '#define'), sondern hatten eine eigene Adresse im Speicher. Und da kann man nunmal reinschreiben. Blöde Sache, damals. Aber so war es nun mal.

[Namenloser]

Zitat:

Zitat von Furtbichler (Beitrag 1232502)

Na, wenn Du ein neues Wort für 'static field', oder 'class var' einführen willst, nämlich 'methoden-statisch'... bitte sehr.

Das eine ist in einer Klasse deklariert, das andere in einer Methode (oder Funktion/Procedure, muss ja nicht zu einer Klasse gehören). Was ist daran so schwer zu verstehen?

[Furtbichler]

Zitat:

Zitat von NamenLozer (Beitrag 1232522)

Zitat:

Zitat von Furtbichler (Beitrag 1232502)

Na, wenn Du ein neues Wort für 'static field', oder 'class var' einführen willst, nämlich 'methoden-statisch'... bitte sehr.

Das eine ist in einer Klasse deklariert, das andere in einer Methode (oder Funktion/Procedure, muss ja nicht zu einer Klasse gehören). Was ist daran so schwer zu verstehen?

Das ist so krank, das ich daran nicht gedacht habe (die lokalen Konstanten, die variabel sind, also gar nicht konstant, und auch gar nicht lokal sondern statisch). Nix für ungut. Hab's jetzt. :thumb:

[himitsu]

Zitat:

Zitat von Furtbichler (Beitrag 1232524)

Das ist so krank, das ich daran nicht gedacht habe (die lokalen Konstanten, die variabel sind, also gar nicht konstant, und auch gar nicht lokal sondern statisch). Nix für ungut. Hab's jetzt. :thumb:

Praktisch mein Code, zu dem ich aber nicht verrate welche Option man dafür aktivieren müsste.