objektorientierte Programmierung - komponentenbasierte Programmierung

[PeterS]

Moin,

eigentlich könnte ich mich auch an
viewtopic.php?f=9&t=13411
anhängen denn meine Frage geht - möglicherweise - in eine ähnliche Richtung, siehe :

Nun ist mein Ziel die Klasse TXY einfacher handhabbar zu machen -- also wenn nötig die Unit der Klasse TXY einzubinden ohne immer einen zusätzlichen Unit-Rattenschwanz mitzuführen. Gleichzeitig möchte ich aber ..

Segen und Fluch der objektorientierten Programmierung ist die Vererbung.
Die zieht einen Rattenschwanz an Units mit sich, von denen man sich nicht lösen kann.
Ich will's mal an einem Beispiel erklären:

Ich habe - mal angenommen - eine Audio-Software (DAW), die hat verschiedene Funktionalitäten
- Bedienoberfläche (GUI)
- Audio-Engine (I/O Interfaces und DSP-Kram)
- File-Management (gleichzeitige Nutzung vieler Files)
- Handling verschiedener File-Formate
- ... und keine Ahnung, was noch alles ..

Jetzt möchte ich mal nur diese Audio-Engine auch in einem anderen Programm verwenden.
Durch Querbeziehungen zwischen GUI, Audio-Engine und File-Management
ziehe ich beim einbinden eines einzigen TObjects ggf. den gesamten Rattenschwanz an Units mit,
die ich gerne getrennt lassen wollte. Es wird irgendwann ein nicht mehr entwirrbares Kneuel von Sourcecode.

Der Haken scheint mir zu sein, daß mir PASCAL (Lazarus) OOP hier vom Konzept her keine Hilfestellung gibt.
Ich kann nicht mal eben - unterstützt von der Sprache - eine unabhängige "Komponente" definieren, siehe auch
https://de.wikipedia.org/wiki/Komponent ... ntwicklung
https://de.wikipedia.org/wiki/Komponent ... ittstellen

Lazarus / Pascal ist leider keine "komponentenbasierte Sprache", sondern "nur" eine objektorientierte.


Meine aktuelle Idee wäre, die Kette der Vererbung ganz weit unten aufzubrechen.

1) Eine Basis-Klasse schreiben, die nur das Interface des TBasisObjekts definiert.
Diese Unit kann ich ohne großen Rattenschwanz überall einbinden.

2) darauf aufbauend das voll funtionierende abgeleitete TMyObject schreiben, das Interface muß aber gleichbleiben.
Ich darf also in abgeleiteten TMyObjects keine Definitionen in public und published hinzufügen, löschen oder überschreiben.

3) In der GUI könnte ich z.B. ein TBasisObjekt als Variable anlegen, damit sind in der GUI
die public und published Funktionen, Variablen etc. von TBasisObjekt bekannt und verfügbar.
Um ein von TBasisObjekt abgeleitetes Objekt zu benutzen, muß ich dann einen Pointer umbiegen:

Code: Alles auswählen

PZumInterfaceVonTMyObject:= TBasisObjekt( @MeineAbgeleiteteKlasse);

( Pseudo-Code .. nur zur Erläuterung )


Ich will das in der nächsten Zeit mal ausprobieren, also ein Dummy-Beispiel-Projekt aufsetzen,
um zu schauen, ob das tatsächlich klappen würde.

Oder gibt es da bereits komponenten-basierte Ansätze, von denen ich noch nichts gelesen habe ?

[af0815]

Grundlegend gibt es noch die Idee, nur auf Interfaces zu programmieren. Damit ist man noch flexibler und komplett entkoppelt. Ist aber wieder weg von der Idee des RAD.

[PeterS]

Soweit ich das verstanden habe, sind Interfaces ja ein definierter Bestandteil von "komponentenorientieren Sprachen".
Das wird aber halt vom objektorientierten Ansatz nicht aktiv unterstützt ..

[PeterS]

Ich habe gerade diesen Artikel gelesen ..
https://de.wikipedia.org/wiki/Abstrakte_Klasse

und ehrlich gesagt habe ich mich damit nie befaßt.

Wären vielleicht abstrakte Basisklassen ein gangbarer Weg,
um Lazarus- (Pascal-) TObjects voneinander zu "entkoppeln" ?

[wp_xyz]

Die ganze Theorie hilft dir nichts, wenn der Package-Autor seine Bibliothek nicht klar strukturiert und überall Querverbindungen zwischen den Units einbaut. Ich kenne die von dir genannte Bibliothek nicht, aber wenn die Audio-Engine so geschrieben ist, ohne dass Bezüge zu den Bedienelemente vorkommen, dann könntest du ein eigenes Package erstellen, in dem nur die Audio-Engine enthalten ist (vereinfach ausgedrückt, natürlich).

Ich glaube, das ganze ist eher ein Problem der Package-Struktur und der Abhöngigkeiten der Units innerhalb des Packages als ein grundsätzliches Problem von OOP. Und auch ein Problem des Überfrachtens von Bilbiotheken mit immer mehr Funktionalitäten, anstatt neue Funktionalitäten in andere Packages auszulagern

[PeterS]

Die ganze Theorie hilft dir nichts, wenn der Package-Autor seine Bibliothek nicht klar strukturiert und überall Querverbindungen zwischen den Units einbaut. Ich kenne die von dir genannte Bibliothek nicht, aber ..

Ich hatte keine konkrete Bibliothek genannt, oder "im Auge".
Mir geht es darum, wie ich selber meine eigenen Programm-Objekte
aufbauen muß damit ich mich nicht selber in diesen Abhängigkeiten verhedder ..

Mir fiel da gerade das folgende Beispiel ein:

Code: Alles auswählen

    ShellListView1: TShellListView;
    ShellTreeView1: TShellTreeView; 

Die verbinden sich über ein Property miteinander, das man im Objekt-Inspector setzen kann.
Aber da ist es ja kein Problem da beide TObjects ja dasselbe Thema behandeln: Dateimanagement.
Da ist es dann egal daß beide TObjects dieselben Units "mitschleppen".

[wp_xyz]

Ich verstehe nicht so recht, was du konkret erreichen willst. TShellListView und TShellTreeView sind in derselben Unit, beide ergänzen sich optimal. Ist deine Frage: Wie kann ich ShellTreeView verwenden, ohne dass ich ShellListView mitgeliefert bekomme? Zum einen hilft der Compiler, der die definitiv nicht aufgerufenen Routinen der ShellListView nicht einbindet, evtl kann man noch mehr mit SmartLinking erreichen. Wenn das nicht reicht, kann ich nur sagen: selbst machen (und dich im drei Jahren ärgern, warum du damals ShellTreeView nicht so schlau gemacht hast, es mit einer ShellListView zusammenarbeitet...)

Fazit: Wenn Komponenten vielseitig verwendbar sein sollen, dann müssen sie halt etwas mehr Code mitschleppen als spezialisierte Versionen, die auf den konkreten Anwendungsfall zugeschnitten sind.

Was ich mit meinem Post oben sagen wollte, ist, dass Biliotheken im allgemeinen aus vielen Units bestehen, dass aber die Abhängigkeiten der Units untereinander oft nicht optimal ausgelegt sind. Zum Beispiel könnte man Funktionalitäten viel besser isolieren, wenn man vielleicht eine Deklaration aus der einen Unit in eine andere verlegen oder eine Gruppe von Funktionen in eine separate Unit auslagern würde. Letzteres passiert z.Zt in Lazarus, da wird viel allgemeine Funktionalität aus der LCL in das Package LazUtils ausgelagert, so dass diese Funktionen aufrufbar sind, ohne die ganze LCL im Boot zu haben.

[PascalDragon]

Segen und Fluch der objektorientierten Programmierung ist die Vererbung.
Die zieht einen Rattenschwanz an Units mit sich, von denen man sich nicht lösen kann.
Ich will's mal an einem Beispiel erklären:

Ich habe - mal angenommen - eine Audio-Software (DAW), die hat verschiedene Funktionalitäten
- Bedienoberfläche (GUI)
- Audio-Engine (I/O Interfaces und DSP-Kram)
- File-Management (gleichzeitige Nutzung vieler Files)
- Handling verschiedener File-Formate
- ... und keine Ahnung, was noch alles ..

Jetzt möchte ich mal nur diese Audio-Engine auch in einem anderen Programm verwenden.
Durch Querbeziehungen zwischen GUI, Audio-Engine und File-Management
ziehe ich beim einbinden eines einzigen TObjects ggf. den gesamten Rattenschwanz an Units mit,
die ich gerne getrennt lassen wollte. Es wird irgendwann ein nicht mehr entwirrbares Kneuel von Sourcecode.

Dann hast du es aber schon schlecht designed. Du solltest die Audio-Engine so gestalten, dass sie keine Abhängigkeiten zur GUI hat, bzw. wenn überhaupt diese durch Interfaces, abstrakte Klassen oder Ereignisse bereitstellt. Genauso kannst du es so gestalten, dass der Dateizugriff durch entsprechende Mechanismen abgedeckt ist. Hierdurch kannst du die Engine separat nutzen (und auch testen, falls du Unittests verwendest).

[PeterS]

Ich verstehe nicht so recht, was du konkret erreichen willst. TShellListView und TShellTreeView sind ..

Mich interessieren TShellListView und TShellTreeView nicht.
Ich habe sie nur als Beispiel genannt.

Mit "komponentenbasierte Programmierung" sind hier nicht die Komponenten in Delphi oder Lazarus gemeint.

Lies doch mal meinen Eingangs-Post.

[PeterS]

Dann hast du es aber schon schlecht designed. Du solltest die Audio-Engine so gestalten, dass sie ..

Ich habe noch garnichts designt.

Meine Frage wäre, wie man es hinbekommt, ohne vorhandene Unterstützung seitens der Sprache PASCAL
unabhängige Lazarus-TObjects zu erstellen, die sich wie in komponentenbasierter Programmierung verhalten.
=> https://de.wikipedia.org/wiki/Komponentenmodell

Und mit "Komponenten" sind hier nicht die Komponenten in Delphi oder Lazarus gemeint.

.. wenn überhaupt diese durch Interfaces, abstrakte Klassen oder Ereignisse bereitstellt.

Das fehlt mir in meinem "Werkzeugkasten".

=>

Wären vielleicht abstrakte Basisklassen ein gangbarer Weg,
um Lazarus- (Pascal-) TObjects voneinander zu "entkoppeln" ?

[PeterS]

Grundlegend gibt es noch die Idee, nur auf Interfaces zu programmieren. Damit ist man noch flexibler und komplett entkoppelt. Ist aber wieder weg von der Idee des RAD.

Kannst Du mir erklären wie Du das meinst mit den "Interfaces", in Lazarus ?
..
Okay, habe da gerade was gefunden, aber das kenne ich überhaupt noch nicht ..
https://wiki.freepascal.org/Interfaces
https://wiki.freepascal.org/Understanding_Interfaces

Ein mir bislang unbekanntes Konstrukt, und dann noch in Englisch .. puh !


EDIT: hab was gefunden - https://de.wikibooks.org/wiki/Programmi ... Interfaces
Ich hoffe, das hilft mir weiter ..

[af0815]

zum Thema gegen Interfaces programmieren wirst du auf Deutsch nichts finden.

Generell kannst du dir ein Interface wie einen Kontrakt (Vereinbarung) vorstellen. Du kannst dann jeden verwenden der dir den Kontrakt erfüllt. Ein extremes windowslastiges Beispiel ist Directshow. Da programmierst du nur gegen Interfaces. Total genial, aber extrem kompliziert.

Leider ist die Programmierung gegen Interfaces noch nicht 100 Prozent in der visulellen Unterstützung von Lazarus verankert. Kann aber sein, das sich da etwas in den letztem 3 Jahren geändert hat.

[PeterS]

Generell kannst du dir ein Interface wie einen Kontrakt (Vereinbarung) vorstellen. Du kannst dann jeden verwenden der dir den Kontrakt erfüllt. Ein extremes windowslastiges Beispiel ist Directshow. Da programmierst du nur gegen Interfaces. Total genial, aber extrem kompliziert.

Ich habe gerade DirectShow8.pas in meinem Repository gefunden,
und da auch "Interface"- Deklarationen gesehen.
Ist mir aber zum nur mal ausprobieren jetzt zu komplex.

Daher habe ich das Beispiel von https://de.wikibooks.org/wiki/Programmi ... Interfaces
mal in ein GUI Programm gegossen.

Entscheidende Funktion hier ist ButtonTestClick()

Code: Alles auswählen

unit MainUnit;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, Forms, Controls, Graphics, Dialogs, StdCtrls,
  TestInterfaceUnit;

type

  { TForm1 }

  TForm1 = class(TForm)
    ButtonTest: TButton;
    ButtonClose: TButton;
    Memo1: TMemo;
    procedure ButtonCloseClick(Sender: TObject);
    procedure ButtonTestClick(Sender: TObject);
    procedure FormClose(Sender: TObject; var {%H-}CloseAction: TCloseAction);
    procedure FormCreate(Sender: TObject);
  private
    //
  public
    Tankstelle1: TErsteTankstelle;
    Tankstelle2: TZweiteTankstelle;
  end;


var
  Form1: TForm1;

implementation

{$R *.lfm}


function HoleTankpreis(Liter: Single; Tankstelle: ITankstelle): Single;
begin
  try
    Result := Tankstelle.BerechnePreis( Liter);
  except
    ShowMessage( 'Die Tankstelle wurde nicht gefunden');
    Result := 0;
  end;
end;


{ --- TForm1 ----------------------------------------------------------------- }
procedure TForm1.FormCreate(Sender: TObject);
begin
  Tankstelle1:= TErsteTankstelle.Create;
  Tankstelle2:= TZweiteTankstelle.Create;
end;


procedure TForm1.FormClose(Sender: TObject; var CloseAction: TCloseAction);
begin
  // Quatsch ?
  //Tankstelle1.Free;
  //Tankstelle2.Free;
end;


procedure TForm1.ButtonTestClick(Sender: TObject);
begin
  Memo1.Clear;
  Memo1.Append( FloatToStr( HoleTankpreis( 50, Tankstelle1) ));
  Memo1.Append( FloatToStr( HoleTankpreis( 50, Tankstelle2) ));

  TRY
    Tankstelle1:= TErsteTankstelle.Create;
    Memo1.Append( FloatToStr( HoleTankpreis( 50, Tankstelle1) ));
  EXCEPT
    ShowMessage( 'Exception on second call of Tankstelle1 ..');
  end;
end;


procedure TForm1.ButtonCloseClick(Sender: TObject);
begin
  Close;
end;


end.

Beim schließen der Form, also bei Tankstelle1.Free;
stürzte das Programm ab, daher hab ich es auskommentiert ..

[PeterS]

Und hier die Unit

Code: Alles auswählen

unit TestInterfaceUnit;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils;

type
  ITankstelle = interface
      function BerechnePreis(Liter: Single): Single;
    end;

    TErsteTankstelle = class(TInterfacedObject, ITankstelle)
    function BerechnePreis(Liter: Single): Single;
  end;

  TZweiteTankstelle = class(TInterfacedObject, ITankstelle)
    function BerechnePreis(Liter: Single): Single;
  end;



implementation


function TErsteTankstelle.BerechnePreis(Liter: Single): Single;
begin
  Result := 1.5 * Liter;
end;


function TZweiteTankstelle.BerechnePreis(Liter: Single): Single;
begin
  Result := 1.3 * Liter;
end;


end.

[PeterS]

Das hier ..

Code: Alles auswählen

  Tankstelle1:= TErsteTankstelle.Create;
  Tankstelle2:= TZweiteTankstelle.Create;

scheint in FormCreate() falsch zu sein,
muß man tatsächlich sowas wie

Code: Alles auswählen

Tankstelle1:= TErsteTankstelle.Create;

vor jedem Aufruf des Interfaces machen ?

Und kein Tankstelle1.Free; ???
Scheint ja ein recht flüchtiger Geselle zu sein, dieser INTERFACE ..


EDIT: hab gerade gelesen .. "Schnittstellen enthalten keine Konstruktoren und Destruktoren."