O.k. die Idee dieses Threads besteht gerade darin, praktischen code zu produzieren und dann daraus Theorie, Terminologie, Konzepte, Klassifizierungen, etc. abzuleiten.
Nur dafür brauche ich eben mehr Ruhe, die ich ja auch bald bekomme (trotz extra gig am 28. + evtl. 29. inklusive real existierender Vorbereitung).
Aber noch ein paar Theorieschnippsel, weil ich das zufällig gestern abend noch im GoF Buch gelesen habe:
- BasicLib: Was jede DB braucht. Ich habe mir mittlerweile abgewöhnt, hier scheinbar "unnötige" Routinen pro App zu entfernen. BasicLib ist BasicLib, und fertig.
- ReportRoutines: Routines für das Logging (wenn erforderlich)
- AgentTools: Some tricky routines to manipulate the agent settings Grin
- CommonAppLib (was die Klasse von Apps - so vorhanden - immer braucht)
- CommonAppUILib (was die Klasse von Apps - so vorhanden - immer braucht)
Wie noch zu sehen sein wird, sind Patterns etwas anderes (soll sich dann aus den Beispielen erschliessen und es wie ihr wisst, geht es nicht um besser oder schlechter).
Das weitestgehend sich auf c++ beziehende GoF Buch von 1995 bezeichnet solche wiederverwendkehrenden Libraries als
a) Toolkits
b) Frameworks
Patterns sind etwas explizit anderes.
Toolkits sind dabei wiederverwendbare Funktionsbibliotheken, die ein breites Anwendungsspektrum für einen Haufen an Stellen in einer Menge von Anwendungen haben, z.B. eine IO-Library oder eben sowas wie die beiden CommonAppxxx Libraries.
Frameworks haben ein enger definiertes Anwendungsspektrum. Z.B. ein Framework um alle möglichen verschiedenen Graphen zu erzeugen, oder pdf Dokumente, oder eben Agenten-Settings zu manipulieren (Notes) oder für Logging.
In Java sind die Toolkits (und die Frameworks, etwa für Regular Expressions) Bestandteil der "core Library". Deshalb sind da so viele Klassen.
Patterns sind etwas weniger konkretes und code ist immer nur ein Beispiel für die Implementierung eines Patterns. Ausserdem sind sie "kleiner". Ein Toolkit oder ein Framework kann immer aus mehreren Pattern bestehen aber ein Pattern nie aus einem Toolkit oder Framework.
Hört sich erstmal esoterisch an, aber die Perspektive ist eben anders. Es ist noch nicht mal kompliziert.
Macht euch nicht so einen Kopf und wartet auf die Beispiele.
Patterns sind ausserdem für die Programmierpraxis etwas sehr konkretes. Gerade Einsteiger-OO Bücher stellen OO in aller Regel zunächst immer aus der Analyse-Perspektive da. Ein Aufgabenbereich wird als Klassen/Objekte wiedergegeben, die miteinander in Beziehung stehen, bzw. miteinander interagieren. Diese Klassen/Objete sind Repräsentationen von der realen Welt (Als Beispiel: Student, Kurs, Raum).
Wirklicher Code wird dann aber aus dieser Ananlyse-Perspektive in eine Design-Perspektive übertragen, woraus dann der code entsteht. Die Anwendung aus dieser viel code-näheren Design Perspektive sieht dann ganz anders aus. Eine Menge an Klassen sind einfach keine Repräsentationen von Objekten in der Realen Welt, sondern mehr so Dinge, die die Anwendung zusammenhalten. (s. Bilder: Eclipse screen shot ist code, was unmittelbar aus Design folgt. Anzahlmässig viel mehr Klassen als in Analyse.)
Und um herauszufinden, welche Klassen man braucht und wie man diese zusammensetzt, um eine Analyse umzusetzen, braucht es eben diese Pattern.
Und es gibt auch nur 23 GoF Pattern (sind aus OO-Sicht die fundamentalsten, die es gibt). Und die sind noch nicht mal gleich "wichtig". Und ausserdem ähneln sie sich teilweise sehr.
wenn das euch verwirrt, tut es als schöngeistiges Gequatsche ab
Axel
Beispiele folgen
