AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Algorithmen, Datenstrukturen und Klassendesign Delphi Wann ist die Zeit für eine eigene VCL-Komponente gekommen?
Thema durchsuchen
Ansicht
Themen-Optionen

Wann ist die Zeit für eine eigene VCL-Komponente gekommen?

Offene Frage von "Sir Rufo"
Ein Thema von Der schöne Günther · begonnen am 17. Jun 2013 · letzter Beitrag vom 17. Jun 2013
Antwort Antwort
Seite 2 von 2     12   
Der schöne Günther

Registriert seit: 6. Mär 2013
6.160 Beiträge
 
Delphi 10 Seattle Enterprise
 
#11

AW: Wann ist die Zeit für eine eigene VCL-Komponente gekommen?

  Alt 17. Jun 2013, 18:45
Puh, das ist jetzt genau das Gegenteil von dem, was ich eigentlich glaubte, tun zu sollen: Für dieses spezielle Objekt eine Komponente basteln, die einen Verweis auf das zu visualisierende Objekt hat, sich von diesem ein paar Daten holt und diese darstellt (eben wie das Ampel-Beispiel).

Klar, wenn ich jetzt anfange, an dem Objekt herumzufummeln und Dinge zu modifizieren - Dann sehe ich das ein. Aber nehmen wir an, ich hätte bislang ein gutes Tutorial über Interfaces in Delphi gefunden. Und ich versemmele es nicht, das Interface später ändern zu müssen. Und ich nutze eh nur Methoden, um passiv Dinge auszulesen. Dann fehlt mir die Fantasie, dort später Probleme zu sehen.
  Mit Zitat antworten Zitat
nahpets
(Gast)

n/a Beiträge
 
#12

AW: Wann ist die Zeit für eine eigene VCL-Komponente gekommen?

  Alt 17. Jun 2013, 19:14
Das mit den Komponenten ist halt ein bisserl Geschmacksache.

Für Fachsoftware habe ich auch schon Komponenten erstellt, die die Fachlogik enthielten. Es gab eine Basisklasse und eine Reihe von abgeleiteten Klassen. Die Basisklasse machte den "Verkehr" vom Objekt in die Datenbank und umgekehrt, die abgeleiteten Klassen waren für die fachliche Logik zuständig.

Die optische Darstellung war streng getrennt, d. h.: Die Daten aus den Komponenten wurden durch entsprechende Methoden in die GUI gebeamt bzw. auch der umgekehrte Weg.

Die Komponenten der einzelnen Fachanwendungen werden pro Fachanwendung in ein Package gepackt. In den Projekteinstellungen kann man (zumindest bei Delphi 7) konfigurieren, welche Packages man nutzen will. Es besteht hier meiner Meinung nach kein Problem mit Versionen. Das Package und die Komponenten gehören zusammen mit der Fachanwendung in die Versionsverwaltung und werden mit der Fachanwendung aus der Versionsverwaltung gezogen. Versionswirrwarr kann hierbei nicht entstehen.

Sicherlich hätte ich hier auch ohne Komponenten auskommen können und einfache Klassen schreiben und nutzen können, aber durch die Komponenten waren diese recht einfach in einem Package zusammenzufassen und die einzelnen Fachbausteine (also Komponenten) standen in der Komponentenpalette zur verfügung.

Wenn Komponenten auch Fachlogik enthalten, dann muss man halt wissen, dass diese Komponente nur für eine spezielle Fachanwendung zu nutzen ist. Dies ist ein organisatorisches Problem.
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.343 Beiträge
 
Delphi 11 Alexandria
 
#13

AW: Wann ist die Zeit für eine eigene VCL-Komponente gekommen?

  Alt 17. Jun 2013, 19:17
@sx2008
Ich kann Dir nicht ganz folgen. Von Geschäftslogik in GUI-Controls hat bisher niemand gesprochen - wenngleich die Ablehnung dergleichen völlig richtig ist.
Wenn passende Komponenten verfügbar sind wird man die natürlich nicht nochmal neu erfinden.
Andernfalls kann man sie einmal erststellen und immer wieder verwenden.
Es macht letztlich keinen Unterschied ob die TLEDArray irgendwoher bezogen oder selbst entwickelt wird.

GUI-Controls sollten ihrerseits so allgemein gehalten sein, dass sie nicht an eine bestimmte Geschäftslogik-Version gebunden sind.
Wenn Du davon ausgehst, dass die Controls ständig mitwachsen und Du auch alte Versionen benutzen willst, dann würde ich die Controls generell dynamisch erzeugen und in der Versionsverwaltung aufnehmen.


@SchönerGünther
Ich denke, Du kannst hier Interfaces (im Sinne von Delphi-Interfaces) erst mal außen vor lassen.
Ob Du Deinem Control ein Objekt oder ein Interface übergibst ist im Grunde egal. Wenn Du eh nur genau eine Datenklasse für Dein sichtbares Control zuweist, dann kannst Du auch einfach das Objekt übergeben.
Interfaces braucht man, wenn man unterschiedliche Klassen mit definierten Schnittstellen benutzen will oder mit DLL´s kommuniziert. (würde ich jetzt so zusammenfassen)
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#14

AW: Wann ist die Zeit für eine eigene VCL-Komponente gekommen?

  Alt 17. Jun 2013, 20:23
Ich persönlich halte nicht viel von selbstgebauten Spezialkomponenten, außer, sie sind allgemeingültig. Ich persönlich habe meine Komponentensammlungen und mehr kommt mir nicht dazu.

Im Endeffekt haben wir es hier doch 'nur' mit einer Darstellung zu tun, die selbst keine Funktionalität beinhaltet, oder?

Die Lösung mit dem DrawGrid ist doch ok, findest Du nicht? Großartig anders wird eine eigene Komponente auch nicht aussehen.

Was Du hier -und das haben ja schon alle gesagt- betreiben musst, ist eher die Trennung von Darstellung und Logik. Nicht, das man das machen müsste, aber wenn Du das machst (jeder macht das, was er am Besten kann), dann wird das wirklich sauber und -wer weiss- vielleicht kannst Du dann deine DrawGrid-Geschichte (die ich in einen Frame packen würde, wie schon vorgeschlagen) nochmal verwenden.
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#15

AW: Wann ist die Zeit für eine eigene VCL-Komponente gekommen?

  Alt 17. Jun 2013, 20:27
Also wenn ich mir deine Komponente so ansehe, dann würde ich die mal wie folgt beschreiben
Delphi-Quellcode:
unit MyControl;

TMyControlItem = class( ... )
  property Caption : string;
  property Color : TColor;
end;

TMyControl = class( ... )
published
  property BorderColor : TColor;
  property BorderWidth : Integer;
  property ItemCount : Integer;
  property Items[Index : Integer] : TMyControlItem;
end;
Dein DatenObjekt sieht nun wohl irgendwie so aus:
Delphi-Quellcode:
unit Data;

TDataChild = class
  property On : Boolean;
end;

TData = class
  // Sigalisierung bei Änderungen über einen Event
  property OnChange : TNotifyEvent;
  // oder eine Event-Liste ;)
  procedure AddOnChange( ANotify : TNotifyEvent );
  procedure RemOnChange( ANotify : TNotifyEvent );

  property On : Boolean;
  property ChildCount : Integer;
  property Childs[Index : Integer] : TDataChild;
end;
Für die Visualisierung baust du dir jetzt einfach einen abstrakten Presenter zwischen dem Objekt und irgendeinem Control
Delphi-Quellcode:
unit DataPresenter;

uses
  Data;

TDataPresenter = class abstract
  // Diese Methode soll aufgerufen werden, wenn Data sich ändert
  procedure DataChange( Sender : TObject ); virtual; abstract;
  property Data : TData;
end;
und konkret
Delphi-Quellcode:
unit MyControlDataPresenter;

uses
  DataPresenter,
  MyControl;

TMyControlDataPresenter = class( TDataPresenter )
  constructor Create( AControl : TMyControl );
  procedure DataChange( Sender : TObject ); override;
  property OnColor : TColor;
  property OffColor : TColor;
  property NilColor : TColor;
end;
P.S. Wenn du Spring4D im Einsatz hast, da gibt es Event<T> der einem einen MultiCast-Event auf die Schnelle hinzaubert

P.S.S. Im Anhang mal eine kleine Demo nach diesem Muster und der Präsentation in einem StringGrid
Angehängte Dateien
Dateityp: zip DataPresenter.zip (891,1 KB, 10x aufgerufen)
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)

Geändert von Sir Rufo (17. Jun 2013 um 21:36 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 2 von 2     12   

 

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 15:24 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