objektorientierte Programmierung - komponentenbasierte Programmierung

[m.fuchs]

Hm, ich verstehe die Fragestellung nicht so ganz.

An einer Stelle schreibst du

Die zieht einen Rattenschwanz an Units mit sich, von denen man sich nicht lösen kann.

dann wieder von Komponentenbasierte Entwicklung. Die bedeutet doch noch viel mehr Quellcode.
Wenn ich mir beispielsweise die Enterprise JavaBeans ansehen, dann ist das ein wahres Monster.

So richtig ist mir nicht klar, was du erreichen möchtest.

• Willst du Abhängigkeiten vermeiden? => Benutze die bereits empfohlenen Interfaces.
  Achtung: Benutze die Direktive {$INTERFACES Corba} um die Referenzzählung zu vermeiden. Dann verhalten sich Interfaces so wie es eigentlich sein soll.
• Möchtest du Abhängigkeiten durch Vererbung vermeiden? => Das Decorator-Pattern kann eine Lösung sein.
• Brauchst du eine vernünftige Trennung von GUI und Logik? => MVC ist dein Freund.

Wenn es dir also tatsächlich darum geht in einem größeren Projekt die Übersicht zu behalten, dann gibt es dafür schon viele Baupläne. Die natürlich auch in Freepascal funktionieren.

[Sieben]

Scheint ja ein recht flüchtiger Geselle zu sein, dieser INTERFACE ..

Die Lebensdauer von Objekten mit Interface, die von TInterfacedObject abgeleitet sind, wird tatsächlich vom jeweiligen Interface bestimmt, was hier ganz gut erklärt ist:

http://docwiki.embarcadero.com/RADStudi ... e_Counting

Den Effekt siehst du zB auch, wenn du den Button in deinem Testprojekt zum zweiten Mal klickst. Der Link am Ende der Seite erklärt dann, wie man das 'zu Fuß' vermeiden kann, die von m.fuchs bereits erwähnte Direktive {$INTERFACES Corba} scheint allerdings deutlich bequemer zu sein.

[PeterS]

An einer Stelle schreibst du

Die zieht einen Rattenschwanz an Units mit sich, von denen man sich nicht lösen kann.

dann wieder von Komponentenbasierte Entwicklung. Die bedeutet doch noch viel mehr Quellcode.
Wenn ich mir beispielsweise die Enterprise JavaBeans ansehe ...

Wenn man aus der PASCAL-Perspektive das Wort "Komponenten" liest,
denkt man natürlich sofort an die Lazarus- / Delphi-Komponenten
(Component Library). Die meinte ich aber hier nicht.
In der Überschrift des Threads hatte ich Komponentenbasierte Programmierung geschrieben,
gemäß dem Modell wie hier zu sehen: https://de.wikipedia.org/wiki/Komponent ... ntwicklung

Ich würde gerne GUI und "Funktionskern" einer Software getrennt halten,
und auch den "Funktionskern" in getrennten Funktionseinheiten halten,
zur Wiederverwertbarkeit. So im abstrakten ist das natürlich schwierig zu beschreiben und zu verstehen.

Ein simples Beispiel wäre z.B. das GUI-Element zur Auswahl von
- Audio-Interface (MME, DS, WASAPI, ..)
- Input
- Output
z.B. als drei TComboBox-Elemente

In der einen Richtung muß das mit Strings aus der AudioEngine gefüttert werden,
in der anderen Richtung müssen diese drei gewählten Werte an die AudioEngine übermittelt werden.
Das würde ich gerne machen ohne daß die ganze Unit-Kette der AudioEngine an der GUI "hängt".

In der AudioEngine passiert da ja derweil eine Menge, der Stream muß gestoppt und geschlossen werden,
neue IOs angewählt, dann muß die Sampling-Frequenz passen,
und dann der Stream neu geöffnet und gestartet werden.

• Willst du Abhängigkeiten vermeiden? => Benutze die bereits empfohlenen Interfaces.
  Achtung: Benutze die Direktive {$INTERFACES Corba} um die Referenzzählung zu vermeiden. Dann verhalten sich Interfaces so wie es eigentlich sein soll.
• Möchtest du Abhängigkeiten durch Vererbung vermeiden? => Das Decorator-Pattern kann eine Lösung sein.
• Brauchst du eine vernünftige Trennung von GUI und Logik? => MVC ist dein Freund.

Das muß ich mir alles mal genau anschauen, scheint mir
auf jeden Fall in die richtige Richtung zu gehen.
Genau mit sowas habe ich mich noch nie befaßt, danke für die Links !

[fliegermichl]

Ich denke, daß das Eventsystem eine mögliche Lösung ist.
So können alle Lazaruscontrols miteinander kommunizieren ohne, daß sich diese gegenseitig kennen müssen.

[m.fuchs]

An einer Stelle schreibst du

Die zieht einen Rattenschwanz an Units mit sich, von denen man sich nicht lösen kann.

dann wieder von Komponentenbasierte Entwicklung. Die bedeutet doch noch viel mehr Quellcode.
Wenn ich mir beispielsweise die Enterprise JavaBeans ansehe ...

Wenn man aus der PASCAL-Perspektive das Wort "Komponenten" liest, denkt man natürlich sofort an die Lazarus- / Delphi-Komponenten
(Component Library). Die meinte ich aber hier nicht.
In der Überschrift des Threads hatte ich Komponentenbasierte Programmierung geschrieben,
gemäß dem Modell wie hier zu sehen: https://de.wikipedia.org/wiki/Komponent ... ntwicklung

Ich weiß, was du meintest und ich habe deswegen die EJB ins Spiel gebracht. Du möchtest ja sicherlich ein fertiges Framework für die Kommunikation der Komponenten untereinander benutzen. Man kann das übrigens auch alles selber und bereits mit den Bordmitteln von Lazarus machen.

Zur Strukturierung eben Interfaces oder ähnliches. Zur Kommunikation Eventsystem, IPC oder alles mögliche auf HTTP-Basis(REST, SOAP, etc.).

Letztendlich ist das eigentlich auch kein Sprach- sondern ein reines Architekturproblem.

[PeterS]

Letztendlich ist das eigentlich auch kein Sprach- sondern ein reines Architekturproblem.

Ja, das ist für mich ein Architekturproblem. Und da ich das nicht beruflich mache,
fehlt mir hier auch der theoretische Unterbau, ich wußte halt nicht recht,
wonach ich im Web suchen soll und wie man das in der Praxis löst.

Mir scheint dieser Ansatz hier auf den ersten Blick am sinnvollsten zu sein:

[*] Brauchst du eine vernünftige Trennung von GUI und Logik? => MVC ist dein Freund.

Framework ..

Du möchtest ja sicherlich ein fertiges Framework für die Kommunikation der Komponenten untereinander benutzen. Man kann das übrigens auch alles selber und bereits mit den Bordmitteln von Lazarus machen.

Was für ein Framework wäre denn aus Deiner Sicht geeignet ?

[m.fuchs]

Ja, das ist für mich ein Architekturproblem. Und da ich das nicht beruflich mache, fehlt mir hier auch der theoretische Unterbau, ich wußte halt nicht recht, wonach ich im Web suchen soll und wie man das in der Praxis löst.

Ist ganz einfach: andere Fragen. Tatsächlich versuche ich bei allem was über ein Minitool hinausgeht wenigstens eine zweite Person kurz mit den Grundideen zu versorgen. Irgendwie ist man alleine sehr schnell betriebsblind. Aber da hast du ja hier alle Möglichkeiten Zweit- und Drittmeinungen einzuholen.

Mir scheint dieser Ansatz hier auf den ersten Blick am sinnvollsten zu sein:

[*] Brauchst du eine vernünftige Trennung von GUI und Logik? => MVC ist dein Freund.

Nutze ich inzwischen fast ausschließlich, wenn es um Software mit Benutzeroberflächen geht. Die im Beispiel vorgestellte Arbeitsweise hat auch noch den Vorteil, dass man immer noch RAD-mäßig die Formulare zusammenklickt. Das hilft beim Layout erheblich.

Was für ein Framework wäre denn aus Deiner Sicht geeignet ?

Das muss ich leider passen, unter Freepascal/Lazarus oder Delphi habe ich keine Erfahrung mit entsprechenden Frameworks, ich baue die Struktur lieber von Hand.
Das kommt auch daher, dass ich unter .NET und PHP entsprechende Projekte mit Castle Project, Spring.NET und Symfony betreut habe. Tatsächlich ist die Einarbeitungszeit relativ hoch, man braucht meist nur einen Bruchteil der Funktionalität und die Konfiguration kann sehr aufwändig sein. Wenn dann noch ein Paketmanager dazu kommt fragt man sich irgendwann, ob man überhaupt noch Quellcode schreibt.
Deswegen versuche ich inzwischen auf solche Monster-Frameworks zu verzichten und suche mir für alle Aufgaben lieber spezialisierte Bibliotheken zusammen. Den tatsächlichen Rahmen implementiere ich unter Verwendung von standardisierten Entwurfsmustern dann schnell selber. Das dauert meist nicht lang.

[PeterS]

Irgendwie ist man alleine sehr schnell betriebsblind.

Genauso ging's mir halt.

Also, vielen Dank daß Du Dein Grundgerüst ModelViewController auf Deiner Website zur Verfügung stellst !
Und auch danke für Deine konstruktive Unterstützung !

Ich werd jetzt mal schauen in wieweit ich damit zurecht komme,
und mein Basis-Konstrukt da mal hineinbauen.

[af0815]

Scheint ja ein recht flüchtiger Geselle zu sein, dieser INTERFACE ..

Die Lebensdauer von Objekten mit Interface, die von TInterfacedObject abgeleitet sind, wird tatsächlich vom jeweiligen Interface bestimmt, was hier ganz gut erklärt ist:

http://docwiki.embarcadero.com/RADStudi ... e_Counting

Den Effekt siehst du zB auch, wenn du den Button in deinem Testprojekt zum zweiten Mal klickst. Der Link am Ende der Seite erklärt dann, wie man das 'zu Fuß' vermeiden kann, die von m.fuchs bereits erwähnte Direktive {$INTERFACES Corba} scheint allerdings deutlich bequemer zu sein.

Man muss das mit der Referenzzählung wissen, hat einiges an Diskussion vor ein paar Jahren gegeben wie ich in die Materie Interfaces eingestiegen bin und auch herausgefunden habe, das da bei Lazarus noch einiges an blinden Flecken gab.
Besonders der Unterschied zwischen Corba und normalen Interfaces wurde da diskutiert, mse hat da paar gute Infos gehabt. Mein letzter Stand dazu ist, Corba sollte man nur nehmen wenn man absolut sicher ist, wenn man weis was man tut und sonst keine Interfaces vorkommen, mix is nix. Ansonsten sollte man sich bei seinem Design die Lebensdauer gut überlegen. Ein Punkt war damals nur, das löschen von Pointern, die man kopiert hatte, Seiteneffekte auslösen können. Es ging damals um Verwendung von Interfaces im Objektinspektor (OI). Der ja genau gesehen ein komplett eigenens Modul ist und sich recht gut verwenden lässt. Und dort sin mit Interfaces ein paar Sachen zu tage gekommen, da noch nicht alles für Interfaces implementiert war. Habe damals mit der Hilfe von Michl was gefixt bzw. hinzugefügt.

Infos dazu:
viewtopic.php?f=18&t=11326
viewtopic.php?f=10&t=11820

tw. auch
viewtopic.php?f=10&t=9362

[PascalDragon]

Mir scheint dieser Ansatz hier auf den ersten Blick am sinnvollsten zu sein:

[*] Brauchst du eine vernünftige Trennung von GUI und Logik? => MVC ist dein Freund.

Du könntest dir auch das Thema Model GUI Mediator anschauen, was ähnlich zu MVC ist.

[PeterS]

... Mein letzter Stand dazu ist, Corba sollte man nur nehmen wenn man absolut sicher ist, wenn man weis was man tut und sonst keine Interfaces vorkommen, mix is nix. Ansonsten ..

Das wird jetzt spannend ..

Ich weiß ja noch garnicht, was ich da tue.
Muß erstmal dieses Konzept begreifen hinter

Code: Alles auswählen

type
  IIrgendwas = interface

Ich habe ja (noch) garnicht vor, verteilte Anwendungen zu schreiben, gemäß
https://de.wikipedia.org/wiki/Common_Ob ... chitecture
Wie sich zwei Exe-Dateien / Programme, auf einem PC laufend, miteinander unterhalten,
oder sogar über Netzwerke, da will ich erst garnicht dran denken.

Aber dann müßte Corba doch auch einsetzbar sein zur Kommunikation
zwischen MainThread und zusätzlichen Threads .. ?
Für sowas hatte ich nämlich mal PostMessage() mißbraucht,
mit einer eigenen MessageQueue / FiFo. Aber das war sehr fragil ..

[PeterS]

Mir scheint dieser Ansatz hier auf den ersten Blick am sinnvollsten zu sein:

[*] Brauchst du eine vernünftige Trennung von GUI und Logik? => MVC ist dein Freund.

Du könntest dir auch das Thema Model GUI Mediator anschauen, was ähnlich zu MVC ist.

Das klingt tatsächlich spannend ! Ah, der Herr Geldenhuys.
Irgendwann und irgendwo habe ich den Namen schonmal gelesen.

Ohne jetzt auf die Schnelle irgendwas im Detail verstanden zu haben,
für mich klingt das so wie das MCV Konzept, aber ohne Iinterfaces.

Like other similar design patterns (Model-View-Controller or the
newer Model-View-Presenter), MGM keeps the model data and graphical presentation
separated. There is also no need to create specialised descendants of GUI components,
as in the case of Model-View-Controller or data-aware GUI controls.

Da jetzt viel Arbeit vor mir liegt, um hinter die Konzepte zu steigen,
frage ich mich natürlich, auf welches Pferd ich setzen soll.
Eine echte "verteilte Anwendung" habe ich ja garnicht vor zu schreiben,
auch nix mit (großen) Datenbanken. Aber um zusätzliche Threads werde ich nicht herumkommen.

Ich möchte nur endlich von dem Blödsinn wegkommen, daß ich mangels Konzept /
systematischer Vorgehensweise wieder im Eifer des Gefechts - und weil es einfacher scheint -
doch wieder die GUI mit dem Unterbau verzahne, mit GlobalVars oder propietären PostMessage-FiFos oder so ..

EDIT: habe gerade Theorie dazu gefunden .. https://en.wikipedia.org/wiki/Mediator_pattern
.. und mehr von Herrn Geldenhuys .. http://tiopf.sourceforge.net/Doc/QuickS ... index.html

[PascalDragon]

Ich habe ja (noch) garnicht vor, verteilte Anwendungen zu schreiben, gemäß
https://de.wikipedia.org/wiki/Common_Ob ... chitecture
Wie sich zwei Exe-Dateien / Programme, auf einem PC laufend, miteinander unterhalten,
oder sogar über Netzwerke, da will ich erst garnicht dran denken.

Bitte miss den Namen COM Interface und CORBA Interface nicht zu viel Bedeutung bei. Auf Delphi/FPC bezogen wären eigentlich die Namen Reference Counted Interface und Raw Interface korrekter.

Ein Reference Counted Interface erbt immer von IUnknown, was die Methoden _AddRef und _Release mitbringt. Der Compiler ruft diese Methoden zum Beispiel bei Zuweisungen oder Parameterübergabe auf, damit die Objektinstanz, welche das Interface implementiert, entsprechend darauf reagieren kann (die Standardimplementierung hierfür ist die in TInterfacedObject, welches einen Referenzzähler hat und sich selbst freigibt, wenn dieser wieder 0 erreicht). Außerdem stellt IUnknown die QueryInterface Methode bereit, wodurch du einfach von einem Interface A zu einem Interface B kommen kannst, wenn die dahinterstehende Objektinstanz das zweite ebenfalls unterstützt (das wird eben in COM auch sehr viel verwendet). In Delphi/FPC ist dies auch durch den as-Operator verfügbar. Auch kannst du ein Interface wieder per as zu einer Klasseninstanz umwandeln, wenn es eine Pascal Klasseninstanz war (geht also zum Beispiel nicht für C++ Klasseninstanzen).

Die Raw Interfaces wurden ursprünglich eingeführt, da angenommen wurde, dass die COM Interfaces für die Verwendung mit CORBA zu viel Ballast mitbringen. Daher auch der Name. Letztlich sind es aber tatsächlich Interfaces, die kein vordefiniertes Elterninterface haben und daher auch keine bestimmten Methoden mitbringen. Daher kannst du eine Klasseninstanz zwar in ein Interface umwandeln, aber nicht umgekehrt oder von Interface zu Interface.

Beide Schnittstellentypen haben ihre Vor- und Nachteile sowie ihre Anwendungsbereiche.

Aber dann müßte Corba doch auch einsetzbar sein zur Kommunikation
zwischen MainThread und zusätzlichen Threads .. ?

Für die Kommunikation zwischen Threads ist in der Tat eine threadsichere Queue oder ähnliches gepaart mit Synchronisierungsmechanismen wie TEvent am Besten geeignet. In vielen, einfachen Fällen kann man auch einfach TThread.Synchronize oder TThread.Queue nehmen.

Ohne jetzt auf die Schnelle irgendwas im Detail verstanden zu haben,
für mich klingt das so wie das MCV Konzept, aber ohne Iinterfaces.

Auch bei MVC sind Interfaces im Object Pascal Sinne nicht notwendig. Ja, du brauchst eine sinnvolle Schnittstelle, aber wie genau du sie umsetzt ist nicht vorgegeben.

[PeterS]

@af0815 hatte geschrieben

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.

Das einzige, was aus meiner Sicht mit RAD rapide=schnell geht, ist das "zusammen-clicken" des GUI.
Nur wenn ich (andere) toll gemachte, fertige Lazarus-Components miteinander verknüpfe,
geht's auch bei Funktionalitäten unter der Motorhaube "rapide" schnell.
Aber vieles was ich brauche, muß ich am Ende doch komplett zu Fuß schreiben, da is eh nix RAD ..

Bitte miss den Namen COM Interface und CORBA Interface nicht zu viel Bedeutung bei. Auf Delphi/FPC bezogen wären eigentlich die Namen Reference Counted Interface und Raw Interface korrekter.

Vielen Dank @PascalDragon für die technischen Erläuterungen !
Mit dem "Interface" Modell muß ich auf jeden Fall erstmal "herum-spielen",
um in der Praxis die Funktionsweise und den Nutzen ganz zu verstehen.

Auch bei MVC sind Interfaces im Object Pascal Sinne nicht notwendig. Ja, du brauchst eine sinnvolle Schnittstelle, aber wie genau du sie umsetzt ist nicht vorgegeben.

Das Beispiel Model GUI Mediator ist in der PDF gut erklärt,
leider aber ohne den kompletten Source-Code auf der CD/DVD
aus der damaligen TOOLBOX-Ausgabe nicht komplett nachvollziehbar.
Ich hab's gestern mal versucht, die Code-Schnipsel sinnvoll in ein Projekt zu gießen,
bin aber (noch) nicht sicher ob es tatsächlich funktioniert.

Aber das hier gibt mir mehr zu denken:

Für die Kommunikation zwischen Threads ist in der Tat eine threadsichere Queue oder ähnliches gepaart mit Synchronisierungsmechanismen wie TEvent am Besten geeignet. In vielen, einfachen Fällen kann man auch einfach TThread.Synchronize oder TThread.Queue nehmen.

Was mir generell noch fehlt in Lazarus, ist ein Modell, eine Kontroll-Struktur, eine massive
automatisierte Unterstützung von Multi-Threads, in / durch Lazarus.
Also quasi unter "Erzeuge neues Projekt" ein Template "Multi-Threaded Application".

Sowas gibt es nicht, und auch meine bisherigen Erfahrungen mit Threads zeigen,
daß dieser fromme Wunsch wohl schwierig zu realisieren ist. Zu unterschiedlich sind wohl
die Arten, wie man Threads nutzt, mal einmalig ("One-Shot"), mal permanent im Hintergrund,
aber nicht zeitkritisch, mal - wie bei Audio und MIDI - mit der Anforderung "Echtzeit", bitte ruckelfrei.
Die Buffer müssen immer voll sein, und "sofort" raus an die Treiber, sonst stottert es.
TThread.Synchronize ist da wohl ungünstig weil es den Thread anhält.

Ich hatte mal ThreadManager.pas genutzt, => https://forum.lazarus.freepascal.org/in ... pic=9708.0
aber in der ursprünglichen Implementierung bringt es keine standarisierten "Kommunikations-Kanäle" mit.
=> https://wiki.lazarus.freepascal.org/Man ... ads_System

So ganz grob betrachtet gibt es eigentlich keinen großen Unterschied, ob ich nun
innerhalb des MainThread, wo das GUI läuft, kommuniziere zwischen Funktionseinheiten, oder zwischen Threads.
(Oder noch extremer: "Verteilte Anwendungen")
In beiden Fällen brauche ich Schnittstellen ("Interfaces"), am besten dieselben.

So, hier hört dann meine Phantasie auf, das krieg ich nicht so leicht in Code gegossen ..

[martin_frb]

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.

Wie andere schon gesagt haben, Komponenten sind noch mehr "Rattenschwanz" (oder ersetzen einen mit dem anderen).
Interfaces sind ok, aber nicht unbedingt sofort nötig. (Kommt drauf an...)

Erster Ansatz können Abstrakte Basis Klassen sein.

Nehmen wir mal Audio vs FilesMgmt.

Nun kenne ich deinen speziellen Fall nicht, aber nehmen wir mal an, Audio zieht Files mit sich, weil irgendwo das Audio auf eine Liste von Files angewandt wird....

Dann benötigt es

Code: Alles auswählen

TContentEntity = class
  procedure Content: TDataStream; abstract;
end;
TContentProvider = class
  function EntitiyCount: intgeger; abstract;
  function Entitiy(AIndex: intgeger): TContentEntity; abstract;
end;

Das zieht kein Files mit sich.

Eine drittes Package kann dann FilesMgmt und Audio kombinieren, indem is TContentFromFilesProvider implementiert.
Da dies in einer 3ten Package ist, hat weder Audio noch FilesMgmt irgendeine Verbindung zum jeweils anderen.

------------------------
Die TContentFromFilesProvider kann entweder als
- Argument übergeben werden
- an eine Property zugewiesen werden
- Oder in "Audio" von einer Factory erstellt werden. Die Factory ist dann in einer globalen var, und wird von außen (von der 3ten Package) gesetzt.
(oder als var "InstanciableCall: class of TContentProvider)