31. Mai 2008 

Methoden in 4D

4D kennt einen ganzen Schwung Methodenarten: Datenbank-Methoden, Projekt-Methoden, Trigger, Formular-Methoden und Objekt-Methoden an Variablen und Feldern. Menüs rufen Projekt-Methoden auf ohne diesen einen Parameter zu übergeben. Startup und Exit führen aus, was grundsätzlich notwendig ist oder nur im Client/Server-Betrieb. Backup und Webconnection habe eigene Datenbank-Methoden. Einen Teil der Aufgaben kann ich in Tabellen-Methoden = Trigger unterbringen. Alles andere, was ich nicht in einer der oben genannten Methodenarten unterbringen kann, wandert in Projekt-Methoden.

Es ist nahe liegend, Methoden an den Objekten anzubinden, an denen sie agieren sollen. Der Button bekommt seine Logik in der Objekt-Methode, dito alle Variablen, das Formular in der Formular-Methode und die Felder ebenfalls in einer Objekt-Methode. Um Methoden und wo sie angebunden darzustellen, lande ich bei dieser Graphik:

image

Ich habe aufgehört, an jedes Objekt eine Methode anzuhängen. Das wird zu unübersichtlich. Nutze ich die Möglichkeiten, Funktionalität der Datenbank kann an vielen Stellen unterzubringen aus, suche ich mir nach einigen Wochen in den eigenen Methoden einen Wolf – erst recht in den Methoden anderer. Das ist nicht Sinn der Sache!

Das Ziel war über viele Jahre, kurze Methoden zu schreiben, die nur eine Aufgabe erfüllen, selten ein/zwei A4-Seiten überschreiten und der 32K-Grenze nicht nahe kommen. Das habe ich lange so gemacht und es war bis zur V6 unumgänglich. Mit dem leistungsfähigeren Methodeneditor der V2003 bin ich davon weg. Mein Beweggrund: wenn ich strukturierter vorgehe, brauche ich die Funktionalität der Datenbanken nicht mehr zu verteilen. Dadurch werden sie einfacher zu warten, jeder Ausbau wird weniger aufwendig und die Seiteneffekte nehmen ab. Die Grenze der Komplexität einer Lösung – sofern sie nicht an 4D, am Rechner oder dem Netzwerkdurchsatz liegt – ist noch mal rausgeschoben.

Konzept

ich habe aufgeräumt. Weder Objekte, noch Formulare, noch Menüs haben eigene Methoden. Sie rufen grundsätzlich nur Projektmethoden auf*. Jede Projekt-Methode hat eine Aufgabe und gehört in eine der drei Kategorien:

Ich stelle mir das vor wie Schichten. Schichten oder Layer sind ein gängiges Konzept, Software zu organisieren und ausbaufähig zu halten. Formular- + Objekt-Methoden und Menüs rufen immer eine Methode der Kategorie Oberfläche, sie sollen diese Schicht nicht umgehen und direkt eine Funktion starten. Mein Konzept habe ich in nebenstehende Graphik verdichtet.

User-Interface

Ganz oben steht das Formular, in der Graphik und wie es der Anwender sieht. Es ist die Oberfläche zu meiner Lösung. Meine Aufgabe ist es, die Aktionen der Oberfläche an die 4D-Engine durchzureichen. Je effizienter mir das gelingt, desto zufriedener sind meine Anwender und desto zufriedener bin ich.

Gut gestaltete Formulare sind das A&O einer guten Lösung, doch manchesmal läßt sich My Companies App nicht vermeiden. In diesem Text geht es mir um den Teil zwischen dem Formular und der 4D-Engine.

Formulare, Objekte, Menüs

Eine Regel, die ich seit Jahren strikt einhalte: keine Objekt- und Formularmethoden, die über den Aufruf einer Projekt-Methode hinausgehen. Felder brauchen keine Objektmethoden. Menüs rufen eine Projekt-Methode ohne Parameter auf oder leiten den Aufruf an den Form event On menu selected durch.
Deshalb funktionieren Formulare und Methode immer mit Klick auf den grünen Pfeil.

Nun zu den drei Kategorien, in die jede Projekt-Methode einsortiert wird:

Oberfläche

Ganz offensichtlich gehören hierher alle Code-Teile, die die Darstellung regeln. Buttons aktivieren/deaktivieren, hierarchische Listen präparieren und auf Clicks, Double Clicks, Selection Change zu reagieren, dito Listboxen. Visible/unvisible sind Oberfläche pur, ebenso die Form events.

Sind Transaktionen Aktionen der Oberfläche, um z.B. ein Abbrechen komplexer Vorgänge – eine Gutschrift mit den Rechnungspoistionen erstellen und trotzdem ein Abbrechen zu erlauben – zu erlauben, muss die Transaktion in einer Projekt-Methode der Kategorie Oberfläche gestartet und beendet werden.

Tabellen- und Feld-Logik

wird in eigenen Projekt-Methoden zusammengefaßt. Alle Änderungen an den Feldern einer Tabelle werden in einer Methode abgearbeitet. Eine solche Methode ist Adresse_Logik und reagiert auf die Änderungen aller Felder, ruft ggf. andere Methoden + Funktionen auf. Also
Case of
:(Modified([ADRESSE]ADR_PLZ))
  PLZListe_Manager("PLZ_geändert";->[ADRESSE]ADR_PLZ;[ADRESSE]ADR_LongInt)

:(Modified([ADRESSE]ADR_Ort))
  PLZListe_Manager("Ortsname_geändert";->[ADRESSE]ADR_Ort;[ADRESSE]ADR_LongInt)

End case

Methoden + Funktionen

Hier finden sich die Dienstleistungsmethoden. Viele Methoden dieser Gruppe kapseln 4D-Befehle, wie String-Operationen, Zugriff auf Hierarchische Listen, Erzeugen und Sichern externer Dokumente, die Einbindung von 4D Write, 4D View und 4D Draw.

Andere sind Manager-Methoden wir der Druck-Manager, der PDF-Manager, der eMail-Manager. Mit etws Aufwand lassen sie sich unabhängig von Oberfläche und Datenstruktur einrichten.

Übertrage ich eine Methode dieser Kategorie in eine neue Lösung, muß hier ggf. nachgebessert werden, wenn Leistungen fehlen. Methoden dieser Kategorie sind ideale Kandidaten für Komponenten.

Tabellen-Trigger

verwende ich in allen Tabellen. Es werden eindeutige Datensatz-IDs vergeben, Datum-, Zeit- und Nutzerdaten eintragen und ggf. das Löschen von Datensätzen unterbunden oder geregelt. Aus Triggern rufe ich Methoden der Kategorie Methoden + Funktionen auf, z.B. um den TimeStamp zu vergeben.

Die logische Überprüfung der Datensätze findet vorher, sozusagen eine Ebene darüber in der Tabellen- und Feld-Logik statt.

4D-Engine

liegt außerhalb meiner Reichweite. Ich kann wählen zwischen Einzelplatz und Client/Server. Mit der V11 wachsen die Optionen.

DB-Pflege

Steht ein neues Feature in einer bewährten Anwendung an, sei es in eine meiner eigenen oder in einer von anderen übernommenen, baue ich die neuen Fähigkeiten nach dem Layerschema auf. Vorhandenen Code übernehme ich per Cut&Paste in die zuständige Methoden-Kategorie, rufe an der alten Stelle den neuen Code auf.

Dieser kurze Aufsatz ist aus der Bitte entstanden, ich möchte mein Layer-Konzept, dessen Vorteile in den Trainings-Sessions schnell klar werden, zum Nachlesen aufbereiten. Gar nicht so einfach. Wo sollte ich ausführlicher werden?

Es bietet sich an, die mittleren Ebenen Tabellen- + Feldlogik und Methoden + Funktionen, in Komponenten der V11 zu überführen. Ich bin gespannt, ob diese konzeptionelle Ebene hinreicht, in der V11 on-the-fly die Datenquelle zu wechseln.

Muß ich heute mal wieder an eine seit Jahren zuverlässig laufende 2003-Anwendung, merke ich sofort, wie wesentlich die 2004.2-Neuheit Pointer auf lokale Variablen ist, um dieses Layer-Konzept umzusetzen.

* Dazu auch 1-2-3

4D Themen: Berichte in Arbeit