Komponenten Programmieren.... wie geht das???

[McLane]

Ok, "zerfleischt" euch doch bitte nicht.

1. Komponenten sind Objekte, somit sind wir in der OOP und jedes Objekt braucht immer einen Vorfahren (Ausnahme: TObject, Mutter aller Objekte) um die ursprüngliche Frage zu beantworten.
[edit] Ergänzung: Mutter aller Komponenten ist natürlich wie schon beschrieben TComponent[/edit]
2. Such dir die Komponente raus, die am ehesten an dem dran ist, was du entwickeln willst. Also wo die meisten Methoden und Eigenschaften mit einem "das soll meine Komponente auch können/haben" Kommentar versehen werden könnten. Leite deine Komponente dann von dieser ab.

MfG McLane

[mkinzler]

Zitat:

Zitat von Hansa

Zitat:

Zitat von 3_of_8

Es ging hier um allgemeine Komponentenentwicklung. Und du hast dazu gesagt, dass man keine Ahnung hat, wenn man jemals von TComponent ableitet...

Es ging nicht um was "Allgemeines", sondern um eine Textverarbeitung. Sorry, aber da bei TComponent anzufangen ? Das ist echt Wahnsinn. :P

@Hansa lies dir mal den kompletten Thread durch, es ging um die Frage:

Zitat:

um ne komponente anlegen zu können, muss ich ja so zusagen ne mutter komponente anlegen...

kann ich auch ne komponente machen ohne "mutter"???

Und auf diese frage bezog sich die Antwort mit der Ableitung von TComponent. Es wurde auch immer wieder erwähnt, daß die Ableitung so spät wie möglich im Vererbungsschema stattfinden sollte.

http://www.delphipraxis.net/internal...=574208#574208

[3_of_8]

Zitat:

Zitat von McLane

Ok, "zerfleischt" euch doch bitte nicht.

1. Komponenten sind Objekte, somit sind wir in der OOP und jedes Objekt braucht immer einen Vorfahren (Ausnahme: TObject, Mutter aller Objekte) um die ursprüngliche Frage zu beantworten.
[edit] Ergänzung: Mutter aller Komponenten ist natürlich wie schon beschrieben TComponent[/edit]
2. Such dir die Komponente raus, die am ehesten an dem dran ist, was du entwickeln willst. Also wo die meisten Methoden und Eigenschaften mit einem "das soll meine Komponente auch können/haben" Kommentar versehen werden könnten. Leite deine Komponente dann von dieser ab.

MfG McLane

Falsch. Eine Komponente ist kein Objekt. Eine Komponente ist eine Klasse und abgeleitet von TObject. Objekte sind was ganz anderes, siehe OH.

[McLane]

Zitat:

Zitat von 3_of_8

Falsch. Eine Komponente ist kein Objekt. Eine Komponente ist eine Klasse und abgeleitet von TObject. Objekte sind was ganz anderes, siehe OH.

Argh, jetzt hab ich mich doch glatt zu solch einer Aussage hinreissen lassen. Sorry...
Um mich selber zu korrigieren: Ein Objekt ist eine Instanz einer Klasse. Eine Klasse beschreibt wie sich das instanzierte Objekt verhällt und was es für Eigenschaften hat. Man programmiert also die Klasse und nutzt dann nachher das Objekt (Ausnahme: Klassenmethoden und Klasseneigenschaften). Die Klasse wird von einem Vorfahren abgeleitet usw. (was ich oben beschrieben habe).

Tut mir tausendmal leid, dass ich vorhin doch glatt diesen Fehler gemacht hatte (man solte halt nebenbei kein Fußball hören) :)

[Der_Unwissende]

[Schon vom roten Kasten behandelt]

Zitat:

Zitat von 3_of_8

Falsch. Eine Komponente ist kein Objekt. Eine Komponente ist eine Klasse und abgeleitet von TObject

Hi, seit doch alle mal etwas entspannter.
Die Instanz einer Klasse ist ein Objekt (im ganz Allgemeinen in der OOP). Geh ich hier von einer Delphi-Komponente aus, so müsste ich jetzt noch die Klasse (also das was von TComponent erbt) und die Instanz (ich würde das Ding auch Komponente nennen) unterscheiden, dass eine ist dann eine Klasse und das andere ein Objekt.
[/Schon vom roten Kasten behandelt]

Aber ist das hier wichtig? Wohl kaum.


Ihr solltet ausserdem diesen lächerlichen Streit lassen, was alles OO ist und was nicht. Also klar, alle Ansätze sind nicht OO denn Delphi ist es schon nicht.
Die OOP beschreibt doch nur einen Interaktionsstil. Da steht nirgendwo (in der einen offiziellen und einzigst wahren Definition :mrgreen: ) dass man nur sinnvolle Programme schreiben darf, bei der immer vom Idealen Vorfahren abgeleitet wird. Den gibt es in der Regel einfach nicht. Und wenn man einen direkten Vorfahren hat, dann hat man den wahrscheinlich schon selbst geschrieben und ob der dann irgendwann mal direkt von TComponent oder von einem Nachfahren abstammt, dass ist doch nun echt egal.
Etwas größere Komponenten bestehen in der Regel eh aus einer Menge von Interfaces und Klassen (teilweise noch abstrakt), also aollte mit etwas Glück eine ganze Vererbungshierachie entstehen und letztlich wird keinen interessieren wie stark OOP das ganze ist (jeder primitive Datentyp ist z.B. schon nicht mehr in der OOP).

Wenn man es also zu ernst mit der OOP nimmt, sollte man vielleicht auf SmallTalk zurückgreifen (oder Ähnliches!)

Gruß Der Unwissende

[Hansa]

Zitat:

Zitat von McLane

...Eine Komponente ist kein Objekt. Eine Komponente ist eine Klasse und abgeleitet von TObject. Objekte sind was ganz anderes, siehe OH...
Eine Klasse beschreibt wie sich das instanzierte Objekt verhält und was es für Eigenschaften hat. Man programmiert also die Klasse und nutzt dann nachher das Objekt

...und zwar so abstrakt, daß nichts dabei herauskommt. :mrgreen:

[Andidreas]

wenn ich mir hier jetzt euer geplänkel so durchless, dann komm ich wieder total durcheinander... :wall:
und dabei wollt ich doch nur mal wissen wie man ne komponente selber schreibt :|

naja aber jetzt nochmal zu meinem verständnis (und bitte zerreist mich nicht in der luft wenn ich was falsches schreib *gg*)

wenn ich ne komponente schreib z.b. ein total abstraktes ding was es bisher noch nie gab... dann nehm ich als "mutter" tcomponent

wenn ich jetzt z.b. ne komponente schreib in der ich strings texte etc. formatier, dann könnt ich das auch von tcomponent ableiten oder mir eine bestehende komponente suchen die weiter unten in der hirarchie ist und näher an meiner geplanten komponente liegt... stimmts????


dann noch gleich ne frage... welche "mutter" komponente würdet ihr nehmen für "textverarbeitung"???

[mkinzler]

Zitat:

wenn ich ne komponente schreib z.b. ein total abstraktes ding was es bisher noch nie gab... dann nehm ich als "mutter" tcomponent

TComponent bietet sich eigentlich nur an , wenn due eine non-visuelle Komponenet schreibst. Besser ist wie schon öfters erwähnt TWinControl, TGraphicControl, TGraphicControl.

Zitat:

wenn ich jetzt z.b. ne komponente schreib in der ich strings texte etc. formatier, dann könnt ich das auch von tcomponent ableiten oder mir eine bestehende komponente suchen die weiter unten in der hirarchie ist und näher an meiner geplanten komponente liegt... stimmts????

Diese Vorgehensweise würde ich immer anwenden.

Zitat:

dann noch gleich ne frage... welche "mutter" komponente würdet ihr nehmen für "textverarbeitung"???

Diese Frage kann ich so nicht beantworten, weil ich nich weiß was die Komponente können soll.

[xaromz]

Hallo,

Zitat:

Zitat von Andidreas

dann noch gleich ne frage... welche "mutter" komponente würdet ihr nehmen für "textverarbeitung"???

da antworte ich doch gleich mit einer Gegenfrage: Was soll denn die Komponente "Textverarbeitung" können? Das ist ein weites Feld...

Gruß
xaromz

[freak4fun]

Stimmt. :mrgreen: Such dir eine Komponente raus, die so dicht wie möglich an dem dran ist, was du machen willst.
Da man unter Textverarbeitung sehr viel verstehen kann, kann ich da keine genaue Antwort geben. Wie wäre es denn mit einem TEdit oder TMemo/TRichEdit? :gruebel:

MfG
freak