Vielleicht bin ich ja einfach nur viel dümmer als der
durchschnittliche Java-Programmierer, aber ich finde "du gibst eine
Callback-Funktion an, die aufgerufen wird, wenn dieser Button geclickt
wurde--weil James Gosling eine Gurke ist, mußt du die Funktion in eine
anonyme Klasse ohne sonstigen Sinn verpacken, sorry" ...
Vielleicht bist Du ja auch viel viel klueger? Die meisten Einsteiger
haetten mit deiner Erklaehrung z.B. einige Probleme:
- Was ist eine Callback-Funktion?
- Wo in meinem Code gebe ich diese Callback-Funktion an?
- Wo in meinem Code rufe ich diese Funtion auf?
- Wer ist James Gosling und warum ist der eine Gurke?
- Was ist eine anonyme Klasse?
Dann gibt es Punkte die Du ueberhauopt nicht erklaehrt hast:
- Warum macht man das denn ueberhaupt so?
- Wann koennte ich das auch so machen wollen?
- Wann sollte ich es besser bleiben lassen?
Ein Buch ueber Design Patterns ist nichts weiter als deine
Erklaehrung, aber hoffentlich mit weniger Bashing und mehr
Information.
...bevor er sein erstes Java-GUI schreiben
darf, muß er erstmal einige Kapitel im GOF-Buch lesen.
Das GOF Buch habe ich nicht empfohlen. Ich finde es ist ein gutes
Buch, aber ich habe es bei meinen Einsteigerbuechern nicht
erwaehnt. Das man es lesen sollte bevor man sich mit Java GUIs
auseinandersetzt hab ich schon gar nicht gesagt.
Für mich gibt es bei Iteratoren schon Muster: In C++ ist das Muster,
daß ich für jeden Container ein-zwei Zeilen boilerplate code schreibe,
was normalerweise zwar verpönt ist, aber wenn der boilerplate code
nicht boilerplate code heißt, sondern Pattern (die Benennung ändert
nämlich wahnsinnig viel daran, daß sich ständig der gleiche Code
wiederholt), dann darf ich das und werde sogar für die Eleganz meines
Codes gelobt; Teil des Musters ist auch, daß ich mich für jede
einzelne Iteration ein wenig gräme.In Smalltalk ist das Muster, daß ich do: schreibe und mit meinem
Programm fortfahren kann, während andere Leute sich noch den Kopf
zerbrechen, wie sie hier am besten das Iterator-Pattern instanziieren.
Du beschreibst hier zwei Implementierungen eines Patterns und bemerkst
(voellig korrekt), das eine der beiden Varianten einfacher ist als die
zweite. Was hat das damit zu tun ob man etwas ueber das Pattern
selber wissen sollte? Fuer mich klingt das eher danach das Du
Iteratoren nicht gerne in C++ implementierst.
Der Name ist do: . Der Name ist map. Der Name ist mapcar und
Konsorten.
Alles Namen von konkreten Implementierungen, und keiner davon nur fuer
die Implementierung eines Iterators zu gebrauchen. Ein Iterator ist
ein Pattern der eine bestimmte Form von Kommunikation zwischen zwei
Objekten beschreibt. Wenn ich Kollegen vorschlage irgendwo in einem
Design einen Iterator zu verwenden, dann haben die ein genaues Bild
davon wie die Schnittstellen aussehen.
Namen vergibt man um zu abstrahieren und zur Kommunikation.
Du selbst machst das auch, ueber dein ganzes Posting verteilt.
Du sprichst z.B. von 'callbacks' und gehst davon aus das ich
weiss was du damit meinst. Ueberleg mal wie praktisch es ist
dass ich mir etwas darunter vorstellen kann.
Ich glaube ein Teil meines großen Problems
mit zu überzeugten Pattern-Anhängern ist, daß sie zu glauben scheinen,
Leute wären zu blöd, um quasi bottom-up Muster zu erkennen, deswegen
muß man sie ihnen von einem total hohen abstrakten Niveau ausgehend
top-down eintrichtern. Spätestens nach der dritten Swing-Komponente
sehe ich, daß sie wohl alle mit dem gleichen Callback-Mechanismus
ausgestattet sind, und bin damit sowohl zeitlich als auch in der
praktischen Erkenntnis dem Heini voraus, dem man gesagt hatte,
Abstraktion ist gut. Wenn ich ein Problem allgemein Beschreiben kann,
dann kann ich es besser erkennen wenn ich es antreffe.
Abstraktion ist der Grund weshalb wir komplexe Probleme ueberhaupt
beaeltigen koennen. Abstraktion macht es moeglich das ich mir morgens
Kafee machen kann, ohne jedes mal die einzelnen Schritte durchzugehen,
die dafuer notwendig sind.
Wenn ich ein Buch ueber Softwareentwicklung schreiben wuerde, dann
ginge es im ersten Kapitel ueber die Bedeutung von Abstraktion. Die
Authoren von 'Structure and Interpretation of Computer Programs' haben
das verstanden. Leider ist das Buch sonst nicht ganz so
einsteigerfreundlich, sonst haette ich es gleich als erstes empfohlen.
und immer schön brav multiplies, bind2nd
und project1st verwenden, weil der Bjarne leider auch falsche
Prioritäten gesetzt hat.
*Klatsch Klatsch!* Bleib doch bitte bei uns! was hat denn jetzt
Stroustrup mit unserer Pattern Diskussion zu tun?
Was kümmert mich, ob GOF Jahrzehnte nach der ersten
Implementierung von Lisp einen tausendsten Namen erfunden haben? Das
Konzept war vor ihnen da und allgemein bekannt.
Was kuemmert es mich wer als erster da war? Hier werden ja keine
Pokale verteilt. Im uebrigen behauptet die GOF nicht, die Patterns in
ihrem Buch erfunden zu haben.
[tex='n'][/tex]
Ja. Ich muß auch wissen, wie ich in meinen Graphen meine Methoden
aufrufe. Und ich weiß es, ohne darüber Bücher zu lesen oder zu
schreiben. Es sagt hier keiner, daß man nicht verstehen soll, was man
tut. Im Gegenteil, ich bin sehr dafür, daß man versteht was man
tut, anstatt krampfhaft zu versuchen, seinem Anwendungsgebiet Kapitel
soundso des-ten Pattern-Buchs überstülpen zu wollen.
Du brauchst also gar keine Buecher zum lernen? Du tippst einfach drauf
los und alles andere kommt von selbst? Das bestaetigt meine Theorie von
oben, das Du einfach viel klueger bist als der Rest von uns: Ich habe
z.B. sehr viel lesen und lernen muessen, bis ich Vererbung
einigermassen verstanden habe. Und was es ueber Methoden alles zu
wissen gibt finde ich auch alles andere als offensichtlich.
Woher weisst du das du etwas wirklich verstanden hast? Ich muss jedes
Jahr ueber mein naives Ich aus dem Vorjahr laechelen. Vielleicht wird
es Dir naechstes jahr ja auch so gehen?
