AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein GUI-Design mit VCL / FireMonkey / Common Controls Delphi OOP Problem: änderungen werden nicht übernommen
Thema durchsuchen
Ansicht
Themen-Optionen

OOP Problem: änderungen werden nicht übernommen

Ein Thema von mimi · begonnen am 25. Dez 2005 · letzter Beitrag vom 1. Jan 2006
Antwort Antwort
Seite 3 von 3     123   
Hansa

Registriert seit: 9. Jun 2002
Ort: Saarland
7.554 Beiträge
 
Delphi 8 Professional
 
#21

Re: OOP Problem: änderungen werden nicht übernommen

  Alt 1. Jan 2006, 00:38
Zuerst mal : Prost Neujahr !

Zitat von mimi:
ist das jetzt eine eigene GUI oder benutzt du delphi komponenten ?
Wenn mein Beitrag gemeint ist : das ist schon Delphi. Tastatur-Ereignisse etc. sind natürlich auch standardisiert. Für mich ist das ein GUI, weil der User mit der gleichen Aktion auch das gleiche Ergebnis produziert, egal wo. 8)
Gruß
Hansa
  Mit Zitat antworten Zitat
mimi

Registriert seit: 1. Dez 2002
Ort: Oldenburg(Oldenburg)
2.008 Beiträge
 
FreePascal / Lazarus
 
#22

Re: OOP Problem: änderungen werden nicht übernommen

  Alt 1. Jan 2006, 08:44
Ja ein Frohers neues Jahr.

Ich meinte eine eigene keine die von Delphi verwendet wird.
Ein komplet eigne mit eigenen funktionen/proceduren und soweiter.
die ohne die VCL auskommt.

Ich möchte nicht alles per TImage regeln sondern über eine eigene GUI regeln.
die dann alle komponenten selbst zeichne wie z.b. ein Fenster, ein Button, ein Label und soweiter.
ich möchte NICH auf TFrom, TButton, TLabel zurückgreifen.
Michael Springwald
MFG
Michael Springwald,
Bitte nur Deutsche Links angeben Danke (benutzte überwiegend Lazarus)
  Mit Zitat antworten Zitat
Der_Unwissende

Registriert seit: 13. Dez 2003
Ort: Berlin
1.756 Beiträge
 
#23

Re: OOP Problem: änderungen werden nicht übernommen

  Alt 1. Jan 2006, 12:42
Frohes Neues euch Beiden! (und allen anderen)

Ja, damit scheidet Hansa's Lösung wohl aus.
Aber willst du komplett auf Delphi Komponenten verzichten oder nur auf Controlls (also die Sichtbaren Dinge). Also wenn du jetzt (noch?) eine TObjectList verwendest, dann wäre das ja auch schon eine Delphi Komponente, da würde ich dann aber über den Sinn des Ersetzens nachdenken.
Jedenfalls ist es auch kein Problem eine GUI mit Delphi Komponenten zu schreiben und diese dann später durch eigene Implementierungen zu ersetzen. Das Zauberwort heißt (überraschender Weise) mal wieder Interfaces.

Ich weiß, die Idee von den Dingern ist noch nicht so wirklich klar (oder?). Also gehen wir mal ein sehr schönes praktisches Beispiel an, du möchtest Plugins ermöglichen.
Die Motivation hinter Plugins ist natürlich allen klar, aber trotzdem noch einmal grob zusammen gefasst:
Plugins ermöglichen es, ein Programm mit weiteren Funktionen auszustatten. Zum Zeitpunkt der Programmerstellung ist dabei noch nicht klar, was für Plugins es geben wird. Der Sinn ist es gerade beliebige Funktionen (nahezu) in ein Programm aufnehmen zu können.

Ok, jetzt muss also das Programm mit etwas umgehen können, dass noch gar nicht existiert. Wie also kann man das eigene Programm darauf vorbereiten mit unbekanntem umzugehen. Man könnte natürlich mit Neuronalen Netzen arbeiten und das Programm lernen lassen und irgendwann (hoffentlich) versteht es dann jedes Plugin, dass kommt, ist aber nicht grade trivial und eigentlich hätte man doch gerne, dass schon das erste Plugin funktioniert.
Muss man also einen anderen Weg gehen. Da man wie gesagt noch nicht weiß was genau kommt, geht man in gewisser Weise den anderen Weg. Man stellt alle (öffentlichen) Daten einem Plugin zur Verfügung. Dieses muss die dann über eine festgelegte Schnittstelle holen und zurück geben (also die Daten). Ganz wichtig ist natürlich noch, das Plugin muss sich bekannt machen können (Registrieren/Deregistrieren), da dass Programm ja sonst nichts vom Plugin weiß.

Definierte Schnittstelle, hm, die nahezu sinngemässe deutsche Übersetzung von Interface (Zwischengesicht tut es auch). Ein Interface macht nichts anderes, als solche Schnittstellen fest zu legen. Da alle Methoden eines Interface nach aussen Sichtbar sind, kann ein Plugin über diese Methoden auf ein Programm zugreifen. Benutzt das Plugin als Schnittstelle ein Interface, wird es nie mehr können als eben genau diese Schnittstellen zu benutzen (das Programm kennt nicht direkt das Plugin und das Plugin kennt nicht direkt das Programm). Beide kennen nur das Interface.

Das ist auch gut so, wenn jmd. ein Plugin für den InternetExplorer schreiben wollen würde und der müsste erst die mind. 4 mio. Zeilen durchgehen (letzter Stand den ich kenne), nun ja...

Ok, was hat das jetzt mit der GUI zu tun? Schauen wir uns doch mal eine beliebige GUI an, warum nicht Delphi. Delphi ist erstmal eine GUI, ok, das ist gut. Delphi hat Komponenten und was noch ganz toll ist, man kann sogar welche nachrüsten. Viele davon stammen nicht aus dem Hause Borland, es spricht also einiges dafür, dass die Erzeuger nicht den Source von Delphi kennen. Und trotzdem funktionieren (die meisten) Komponenten wie sie sollen. Warum?
Nun ja, Delphi macht natürlich nichts anderes als ein Interface zur Verfügung zu stellen. Es ist natürlich etwas komplexer als ein in Delphi geschriebenes Interface (immerhin gehört der Programmcode ja mit zu dem was Delphi verstehen muss), aber es ist an sich auch nur ein Interface.
Wichtig ist, wenn ein Komponente benutzbar sein soll, muss diese über eine festgelegte Methode registriert werden und ebenso wird eine Komponente über ein festgelegte Methode entfernt.
Dabei ist halt nur der Name der Methode sowie die Parameter bekannt. Man weiß natürlich auch was die Methode leistet, aber es interessiert einen i.d.R. nicht, was intern gemacht wird. Deshalb benutzt man hier ein Interface.
Wenn Delphi Komponenten nun anders in 2005 registriert als in 7, dann störrt einen das nicht (sehr idealisierte Vorstellung, die durch Änderungen an Interfaces zu nichte gemacht wird).

Genauso ist es mit deiner GUI, legst du nur die Schnittstellen fest, kannst du die GUI beliebig erweitern. Es muss halt nur eine Möglichkeit geben, neues bekannt zu machen. Würdest du ein Delphi-Form benutzen, was zusätlich ein MainForm-Interface implementiert, dann könntest du dies auch später durch eine beliebige andere Implementierung des MainForm-Interfaces ersetzen.
Du abstrahierst also wieder einfach vom Konkreten (deshalb solltest du dir immer noch über die Beziehung der einzelnen Interfaces Gedanken machen).

Gruß Der Unwissende
  Mit Zitat antworten Zitat
Hansa

Registriert seit: 9. Jun 2002
Ort: Saarland
7.554 Beiträge
 
Delphi 8 Professional
 
#24

Re: OOP Problem: änderungen werden nicht übernommen

  Alt 1. Jan 2006, 13:57
Zitat von mimi:
..ich möchte NICH auf TFrom, TButton, TLabel zurückgreifen.
Da stellt sich allerdings jetzt die Frage nach dem Sinn des ganzen. Geht es um ein Experimental-Programm ? Weil ein ernsthaftes Programm wird man so kaum hinkriegen. Oder gehört das eher in die Kategorie "Wie baue ich mir am einfachsten aus Eisenerz ein Auto ?" Aber egal wie. Die Anleitung zu dem Vorhaben findet sich in der VCL. Dann mußt Du noch tief in die WinAPI-Programmierung einsteigen und Dir darüber klar sein, daß das Programm in absehbarer Zeit als unsicher gelten wird und deshalb nur in einer Win-Box laufen wird.
Gruß
Hansa
  Mit Zitat antworten Zitat
Der_Unwissende

Registriert seit: 13. Dez 2003
Ort: Berlin
1.756 Beiträge
 
#25

Re: OOP Problem: änderungen werden nicht übernommen

  Alt 1. Jan 2006, 14:14
Zitat von Hansa:
Da stellt sich allerdings jetzt die Frage nach dem Sinn des ganzen. Geht es um ein Experimental-Programm ?
Nun ja, Mimi sagte doch ziemlich am Anfang, dass es nur um ein Programm geht um mal in die OOP rein zu schnuppern. Natürlich dürfte es etwas mühselig werden alle Komponenten per Hand zu schreiben und daraus eine (sinnvolle) tolle GUI zu erstellen, aber darum ging es soweit ich mimi verstanden habe nie.
Nur um ein Fenster auf das erstmal ein Label und ein Button gesetzt werden kann (keine vollwertige GUI, nur ein erster Schritt
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 3 von 3     123   


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:47 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz