Hi,
Ich habe mal nachgeschaut:
1. Ich habe ein Error-Objekt, das in einer meiner Applikationen bestimmte Fehler über Systemgrenzen zum Client transportiert. Das könnte man als
Exception-Objekt bezeichnen, aber das es in meiner Hierarchie ein Paket-Objekt ist (eins, das sich verschicken kann), habe ich es anders gewählt. Das Objekt wird in der Mittelschicht erzeugt und zum Client transportiert. Dort kann es eine
Exception verursachen oder z.B. einen besonderen Dialog anzeigen, um diese
Exception (oder Konflikt) aufzulösen.
So, was ist, wenn ich im Client selbst so eine
Exception benötige? Ich habe nicht die gleiche Information wie im Server, brauche aber diese besondere
Exception. Da das sematisch mit meinem TErrorObject zusammenhängt, habe ich eine 'Class Procedure TMyErrorClass.CauseException'. Die kann ich auslösen und gelange dann wohlgeordnet in den Programmfluss der Exceptionbehandlung.
Anderes Beispiel: In meinem
DBMS existiert eine Klasse, die Streams in der
DB verwaltet. Diese Klasse arbeitet mit einer 'Root-Page', in bestimmte Informationen stehen. Wenn ich diese Rootpage erzeugen will (in einer brandneuen
DB), benötige ich keine Instanz eines 'TPagedStreams', sondern nur die 'Class Function CreateRootPage'.
Natürlich kann man das anders lösen, aber ich habe diesen Weg gewählt und finde es eben übersichtlicher, wenn eine Klasse nicht nur mit einer Instanz arbeiten kann, sondern auch die Vorbereitungen treffen kann, um diese Klasse überhaupt verwenden zu können.
Wenn man eine Klasse TNTFSDirectory hat, dann könnte man dann eine "Class Function TNTFSDirectory.CreateRoot" implementieren. Natürlich kann man dafür auch eine Klasse 'TNTFSSystem' schreiben und dort die Methode 'CreateRootDirectorY' implementieren, aber dann hätte man die 'Business logic' der Directory an zwei Stellen: Zum einen in den Methoden der TNTFSDirectory' und zum Anderen in der semantisch übergeordneten Klasse 'TNTFSSystem'. Und widerspricht meiner Prämisse, Business Logic zu konzentrieren.