Neue Eigenschaft für Image und Label

[Hansa]

Zitat:

Zitat von _frank_

wo sind da deine Bedenken? ist in meinen Augen ein sehr sparsamer / übersichtlicher code und OOP ist das auch, trotz fehlender Vererbung des Ursprungscontrols

Meine Bedenken ? Also : man braucht etwas TImage ähnliches, aber nicht das Identische, weil ein Zusatzfeld in der Komponente erwünscht ist (im OI). Quasi Kleinigkeit. Da fange ich doch nicht bei Null an, sondern erweitere das TImage um diese Eigenschaft (siehe Jelly) und basta. Der hat doch sogar beschrieben, wie das Ding dann in die Komponentenpalette kommt.

Natürlich kann man auch das Tag benutzen, dann ist das aber auch schon verbraucht und kann nicht notfalls für andere Zwecke benutzt werden. Es geht hier auch nicht so sehr um Vererbung, sondern eher um Wiederverwendung des Source-Codes. Siehe VCL. Manchmal ist es schon etwas schwierig, einen Vorfahren einer Komponente zu finden. Das ist nämlich fast nie ein TWinControl usw.

[Jelly]

Zitat:

Zitat von Hansa

Es geht hier auch nicht so sehr um Vererbung, sondern eher um Wiederverwendung des Source-Codes.

Auch wenn ich das Beispiel der Vererbung geschrieben hab... Es ist nicht immer Wiederverwendbarkeit nötig. Und es gibt daher auch nicht immer pauschal richtige Lösungen und alle anderen sind falsch. Es ist durchaus legitim, anstatt Vererbung, eben über Aggregation das Ganze zu verwirklichen.

[Hansa]

Zitat:

Zitat von Jelly

..Es ist nicht immer Wiederverwendbarkeit nötig...

Na dann aber : gute Nacht. :mrgreen: Ehrlich gesagt kann ich mir kein vernünftiges heutiges Programm mehr vorstellen, welches ohne OOP Konzepte auskommt. Liegt vielleicht auch daran, dass ich das schon ewig benutze, also seit TP 5.5. Man bedenke einmal, was hier lediglich gefordert ist : ein Zusatzfeld und zwar im OI, also published. Grundlage ist ein TImage. Was liegt da näher, als das TImage zu erweitern ? Wieso soll da eine eigene Standard-Klasse her, die dann irgendwie "angebunden" wird ? :gruebel:

[alzaimar]

WEnn ich allein in meinem Kämmerlein vor mich hin programmiere, dann kann ich Controls aufbohren und ableiten, wie ich lustig bin. Aber wenn ich in einem Team arbeite, geht das nicht so einfach, denn schließlich muss so eine Komponente ja auch installiert werden.

Wir haben eine feste Anzahl von Zusatzkomponenten, und wenn hier jemand auf die Idee käme, in seinem Code einfach mal ne neue Komponente zu entwickeln, dann darf er putzen gehen.

Ich würde auch dazu tendieren, die zusätzlichen Eigenschaften über die Tag-Eigenschaft an ein Image anzuhängen. Tag ist zwar ein Integer, aber durchaus dazu gedacht, ein ganzes Objekt mit zu speichern. Man muss es nur im Code ordendlich dokumentieren.

Und hansa, OOP beschränkt sich ja nicht auf die GUI.

[Jelly]

Zitat:

Zitat von alzaimar

Und hansa, OOP beschränkt sich ja nicht auf die GUI.

und...
OOP ist nicht nur Vererbung. Stichwort: Komposistion, Aggregation usw.

[Hansa]

Zitat:

Zitat von alzaimar

..Wir haben eine feste Anzahl von Zusatzkomponenten, und wenn hier jemand auf die Idee käme, in seinem Code einfach mal ne neue Komponente zu entwickeln, dann darf er putzen gehen..

Aha, bist wenigstens humaner, als die Telekom. :mrgreen: Aber ich bleibe dabei : immer möglichst einen verwandten Typ auswählen und diesen erweitern. Im Team ist Kommunikation gefordert, also eine genaue Abstimmung. Sonst geht nichts. Wird zwar jetzt etwas OT, aber bei mir gibts außer für Testzwecke kein "Label1" oder "Edit56". Es gibt ja auch Hilfsmittel (GExpert) usw.

[shmia]

Ich möchte die Diskussion hier nicht unnötig ausweiten, aber ich ändere/erweitere Controls nur dann,
wenn mir keine andere Wahl bleibt.
Controls (oder Komponenten ganz allgemein) sollten so programmiert werden, dass sie allgemeingültig in allen
Anwendungen einsetzbar sind.
Wenn man die Sache aus dem Blickwinkel MVC (Modell-View-Controller) anschaut, dann sieht man ganz klar,
dass ein TImage zum Bereich View gehört.
Dagegen gehört das property ausgewaehlt in den Bereich Modell bzw. Controller.
==> auch wenn aus OOP-Sicht die Vererbung als Lösung erscheint zeigen doch neuere Entwicklungen (MVC), dass man es so nicht abbilden sollte.

[_frank_]

ich sehe das ähnlich,
ich leite nur neue Komponenten ab, wenn meine Erweiterung Zugriff auf die Eigenschaften der Komponente benötigt (z.b. ich male selber auf dem Canvas der Kompo rum). Dient meine Erweiterung lediglich der Datenspeicherung, auf die das Hauptprogramm zugreifen will, erstelle ich mir eine unabhängige Klasse und benutze das Objects, Data bzw. Tag-Property um die Verknüpfung zur visuellen Komponente herzustellen.
Gerade bei OpenSource-Programmen oder in der Team-Entwicklung ist es meiner Meinung ungünstig, immer wieder neue Komponenten wegen nicht-visueller Erweiterungen zu installieren/upzudaten.

Mich stört es z.b., wenn ich ein fremdes Programm kompilieren will und erstmal 20 Komponenten installieren muss (teilweise erstmal suchen und downloaden), um das Projekt öffnen zu können. :wall:

ich denke mal, wir könnten die Diskussion unendlich fortsetzen :) aber es sollten schon die Vor- und Nachteile diverser Vorgehensweisen erläutert werden...wann welches Verfahren sinnvoller ist, muss jeder selbst entscheiden.

MFG Frank

[Hansa]

Zitat:

Zitat von _frank_

...
Mich stört es z.b., wenn ich ein fremdes Programm kompilieren will und erstmal 20 Komponenten installieren muss (teilweise erstmal suchen und downloaden), um das Projekt öffnen zu können. :wall:

Eigene Komponenten braucht man wohl kaum groß zu suchen und downzuloaden. In der Praxis werden die Komponenten in Packages gepackt. Compilieren, installieren und fertig. Ich brauche z.B. zwingend 3 Packages an DB-Komponenten und 3 eigene. Selbst bei Delphi-Neuinstallation sind das allerhöchstens 5 Min Zeitaufwand mehr. Wie lange braucht Delphi alleine ? :wink:

Das angesprochene MVC-Konzept ist doch schon ca. 25 Jahre alt, oder ? Zumindest kann von "neu" keine Rede sein. Hab gerade nachgeguckt : BP 7.0 ist laut Handbuch immerhin Jahrgang 92. Delphi 1 ist Copyright 1995. Ja, habe das alles noch. :mrgreen: