Entwurfsmustergenerator

Re: Entwurfsmustergenerator

Sag bescheid, wenns fertig ist

Nein, ernsthaft: Nach und nach werden die Unternehmen eher auf Eclipse setzen, dann kommst du mit einem SE80-Wizard nicht weit.... Und nach meiner Erfahrung ist man mit Wizards auch nicht schneller als ohne. Und bei der Namensvergabe kommt in meinen Augen der Projektbezug vor das Pattern, weil das Pattern Bestandteil des Projektes ist und nicht andersrum. Hinzu kommen die unsäglichen Namensvorgaben einiger Kunden, die mal die einen, mal die anderen Präfixe vorschreiben....

Re: Entwurfsmustergenerator

Hallo Enno,

da du scheinbar mehrere Fragen gleichzeitig aufwirfst versuche ich das mal der Reihe nach zu machen.

1.) Dein Vorschlag welche Interfaces Klassen du anlegst würde ich etwas weiter fassen.
- Zunächst definiere dir doch bitte ein allgemeines Interfaceconstruct:
- Ein (leeres) Top-Interface, welches sich einfach z.B. ZIF_DP_OBSERVER nennt - Das wird deine Klammer sein um allen späteren Anwendern zu zeigen, dass du gerade ein Observerpattern verwendest.
- Jetzt legst du für jede deiner Komponenten ein weiteres Interface an, welches das oben angesprochene Interface inkludiert ( also. z.B. ZIF_DP_OBSERVER_OBSERVER, ZIF_DP_OBSERVER_SUBJECT, ZIF_DP_OBSERVER_COBSERVER ( concrete observer ), ZIF_DP_OBSERVER_CSUBJECT ).
Damit hast du schon mal die Grundstruktur des Observerpatterns generiert.

Jetzt kommt es auf den Abstraktionsgrad an, welchen dein Wizard erzeugen soll. Willst du z.B. den aktuellen Status des konrekten Subjekts schon im Wizard abfragen? Oder willst du eine sehr allgemeine Referenz auf den Status nur in einem der o.a. Interfaces ablegen.
Willst du schon implementierende Klassen anlegen und was in den implementierenden Klassen willst du schon selber ausprogrammieren bzw. was willst du allgemein gültig halten.
Auf jeden Fall sollten für die spezielle Ausprägung des zu erzeugenden Patterns jeweils die korrespondierenden allgemeinen Interfaces inkludiert werden.

2.) Bisher muss sich der User bei Einstieg entscheiden, welche Komponenten er anlegen will. Bei deinem Beispiel sind aber gerade die Observerklassen evtl. noch gar nicht bekannt. Es sollte eine Möglichkeit geben mit dem Wizard zu einer speziellen Ausprägung des Observerpatterns später weitere Observer anzulegen.

3.) Du willst irgendwie kenntlich machen welche Objekte zu dem Pattern gehören. Auch hier kannst du mit (leeren) Interfaces weiter machen. Lass deinen Wizard beim Anlegen der speziellen Interfaces ein neues Interface erzeugen ( ZIF_DP_OBSERVER_0000001 ) und lass alle deine speziellen Interfaces auch dieses Interface inkludieren. Bei deinem Beispiel hätte dann z.B. das concrete subject folgende Interfaces. ZIF_DP_OBSERVER_CSUBJECT ( --> durch Interfaceinkludierung würden dann bestimmt auch ZIF_DP_OBSERVER_SUBJECT und ZIF_DP_OBSERVER in der Klasse zu finden sein ) und ZIF_DP_OBSERVER_0000001. Jetzt kannst du im Navigationsbaum bei den das Interface ZIF_DP_OBSERVER_0000001 implementierenden Interfaces/Klassen sehen, welche Objekte zu der speziellen Ausprägung des Patterns gehören. Falls du mit einer implementierenden Klasse startest würdest du hier auch Relationen finden, die nicht auf deiner Beispielimplementierung beruhen sondern alles lieber selber machen.

4.) Ad SAPLINK-Nugget: So etwas könntest du evtl. mit einer WEB-Anwendung machen - aber SAPLINK agiert sehr stark im SAP-System selber und du wirst dich da dann wohl auch bewegen müssen. Grundsätzlich halte ich SAPLINK für durchaus brauchbar für deinen Zweck - aber je nachdem was du vorhast solltest du dir evtl. einfach anschauen was die Klasse ZSAPLINK_CLASS macht ( dort die Methode, die eine Klasse in das SAP-System einbaut ) und die dort verwendeten FuBa selber nutzen um das für deinen Wizard Wesentliche zu erzeugen.