AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Sprachen und Entwicklungsumgebungen Object-Pascal / Delphi-Language Delphi [Records] Codeoptimierung bei Übergabetypen

[Records] Codeoptimierung bei Übergabetypen

Ein Thema von Igotcha · begonnen am 21. Sep 2004 · letzter Beitrag vom 23. Sep 2004
Antwort Antwort
Seite 3 von 3     123
oki

Registriert seit: 30. Dez 2002
Ort: Brandshagen
1.819 Beiträge
 
Delphi 2007 Professional
 
#21

Re: [Records] Codeoptimierung bei Übergabetypen

  Alt 23. Sep 2004, 09:06
Hi maximov,

mein erster Gedanke war auch der Hinweis auf ein Object. Persönlich überlege ich aber auch immer erst was ich noch für zusätzlichen Aufwand betreiben muß.
Üblicherweise verwende ich Records immer dann, wenn ich relativ viele Daten in Funktionen und Procedure übergeben muß. Ich finde es einfach nervig Methoden mit einem Rattenschwanz von Parametern zu verwenden. Bei Tree's ist man im Parameter Data nun mal an den Pointer gebunden (auch gut so). So lange es dann auch nur um das Halten von Daten geht, verwende ich recht gerne Records.
Müssen die daten aber "manipuliert", bearbeitet oder Ausgewertet werden, so schreibe ich mir lieber eine eigene Klasse. Das macht den eigentlichen Quellcode gerade bei mehrfachen Zugriffen kürzer und übersichtlicher. Der Schreibaufwand für diese Klassen ist dann aber erst mal größer(vorausgesetzt man macht es "ordentlich").

Bei diesem Beispiel wissen wir nun nicht genau wieviel Bearbeitungsaufwand folgt. Grundsätzlich lege ich auch Records bei Tree's an. Ich finde den Hinweis für die Verwendung einer Klasse aber intreressant. Zumindest müßte Igotcha in seiner Form-Unit nicht seperate Methoden für die Datenbearbeitung platzieren die mit dem Fenster in der Form nichts zu tun haben, sondern eigentlich datenbezogen agieren. Mir fällt es bei dieser Art der Programmierung selber immer wieder schwer nach längerer Zeit zu verstehen, was ich da geprogt habe.

Gruß oki
  Mit Zitat antworten Zitat
oki

Registriert seit: 30. Dez 2002
Ort: Brandshagen
1.819 Beiträge
 
Delphi 2007 Professional
 
#22

Re: [Records] Codeoptimierung bei Übergabetypen

  Alt 23. Sep 2004, 09:25
hi,

ich hab mal einen Ansatz für so ein Object zusammen geschrieben.
Delphi-Quellcode:
type TMonatArr = Array [0..16] of double;

type
  TDaten = class(TObject)
  private
    FGroupid: integer;
    FGTyp: integer;
    FGrid: integer;
    FPid: integer;
    FGS3: String;
    FGColor: String;
    FGS2: String;
    FGOP1: String;
    FGOP2: String;
    FGS1: String;
    FGBez: String;
    FMonat: TMonatArr;
  protected
  public
    property Gid: integer read FGrid write FGrid;
    property Pid: integer read FPid write FPid;
    property Groupid: integer read FGroupid write FGroupid;
    property GBez: String read FGBez write FGBez;
    property GTyp: integer read FGTyp write FGTyp;
    property GColor: String read FGColor write FGColor;
    property GS1: String read FGS1 write FGS1;
    property GOP1: String read FGOP1 write FGOP1;
    property GS2: String read FGS2 write FGS2;
    property GOP2: String read FGOP2 write FGOP2;
    property GS3: String read FGS3 write FGS3;
    property Monat: TMonatArr read FMonat write FMonat;
end;
hier können jetzt alle Methoden eingearbeitet werden, die Aktionen für die zu haltenden Daten durchführen, ohne dass mann dafür von "Außen" sorgen muß.

Wie gesagt, nur um Daten zu halten ist mir der Aufwand zu groß. Geht es dann aber ein Stück weiter, machts dann mit classen wieder Spaß.

Gruß oki
  Mit Zitat antworten Zitat
Igotcha

Registriert seit: 22. Dez 2003
544 Beiträge
 
Delphi 2006 Professional
 
#23

Re: [Records] Codeoptimierung bei Übergabetypen

  Alt 23. Sep 2004, 09:55
Hallo zusammen,

ich finde es toll, dass Ihr Euch weiter um das Thema bemüht

Deshalb ein paar Infos zu mir und dem Programm:

Ich bin kein studierter Informatiker, sondern studierter Kaufmann mit langjähriger Hobby-Programmiererfahrung und habe in meinem Beruf als Berater in einem Produkt-und Softwarehaus für einen Kunden eine ähnliche Lösung in Excel entwickeln müssen. Excel war Kundenwunsch. Das Ganze ist ein hierarchisches Prognosetool, welches Prognosewerte von z.B. Bereichsleiterebene auf Geschäftsbereichsebene bis hin zur Konzernebene aggregiert und später auswertet. Dazu werden dem Anwender seine Plandaten und die Istdaten in das System eingespielt und dieser hat z.B. wöchentlich eine Prognose über die künftige Entwicklung abzugeben. Zusätzlich wird noch eine Abweichungsübersicht erstellt, damit der Anwender alle Informationen parat hat, für die er verantwortlich ist, etc.

Dann sollte (die Betonung liegt auf sollte) ich für unseren Geschäftsbereich ein erweitertes System dieser Art aufsetzen (mit weniger Anwendern) woraufhin ich unseren Chef in Bezug auf Excel aus meiner Erfahrung damit vorgewarnt habe - hat nichts genützt. Natürlich hat sich gezeigt, dass Excel für so etwas mehr schlecht als recht geeignet ist (Thema Wartung) und irgendwann habe ich mir privat überlegt, das Ganze "richtig" zu programmieren. Mit zentraler Datenbank, etc. Momentan habe ich einen Stand erreicht, der funktioniert - sozusagen die 1.0 Version.

An Objekte habe ich natürlich auch gedacht, bin aber aus zwei Gründen erstmal davon abgekommen:

- der erste Grund war, dass ich überhaupt erstmal eine Komponente finden musste, die es mir ermöglich, die "Vision" des Programms visuell zu verwirklichen (das ist aus Anwendersicht ein sehr wichtiger Punkt). Da bin ich dann irgendwann beim VirtualTreeView gelandet,
- der zweite Grund war, mit dem Programm schnell so etwas wie eine Machbarkeitsstudie zu realisieren - also zu zeigen, dass es überhaupt so geht, denn ich möchte das Programm evtl auch vermarkten.

Zum Programm:

Jeder Anwender sieht in dem Programm vier Sichten auf seinen Bereich:

- Prognose, Ist, Plan und Abweichung, jeweils in Form eines VTVs
- jede Sicht besteht aus ~ 140 Zeilen (Erlöse, Kosten, statische Zeilen), wobei in 3 der 4 VTVs jede Zeile aus o.g. Recordstruktur besteht (die Abweichungssicht hat ein kleineres Record)
- jede Sicht wird dynamisch strukturiert aufgebaut (die Struktur ist konfigurierbar, kann also je nach Organisationsbedürfnissen angepasst werden)
- basierend auf dieser Struktur werden Gruppen-, Untergruppen-, Zeilen- und Quartalssummen automatisch generiert
- zusäzlich sind "statische" Zeilen möglich. Also Zeilen, die das mathematische Ergebnis aus bis zu drei anderen Zeilen darstellen. Beispiel: Ebit_1=Umsatz-Kosten
- grundsätzlich ist es möglich, jede Zeile als berechnetes Ergebnis von bis zu 3 anderen Zeilen darzustellen,
- Eingaben in der Prognosesicht führen dazu, dass natürlich die Prognosesicht aktualisiert werden muss und die geänderten Daten in die Datenbank geschrieben werden. Zusätzlich ändert sich aber auch dabei die Ist-Sicht, denn diese ist wie folgt aufgebaut: sofern Istdaten für den Monat vorhanden sind, zeige die Istdaten an, andernfalls die entsprechenden Prognosedaten. Wenn wir also z.B. die Istdaten bis August vorliegen haben, werden für JAN-AUG die Istdaten und für SEP-DEZ die Prognosedaten angezeigt, um das vorraussichtliche Jahresergebnis zu ermitteln
- dann gibt es Exportfunktionen nach TXT und Excel
- etc.

Objekte sind in einer zukünftigen Version sicher eine Alternative, aber da würde ich mich erst ransetzen, wenn ich genau weiss, was ich alles benötige. Bisher steht der kaufmännische Aspekt (also die inhaltliche Funktionalität) des Programms im Vordergrund.

Gruß Igotcha

EDIT: Hab mal einen Screenshot beigelegt.
Miniaturansicht angehängter Grafiken
kp_002.gif  
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

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 08:06 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