Hallo Uwe,
ich moechte unbedingt auf Dein Kochrezept reagieren: sich selber
kochende Kartoffeln oder sich selber servierende Essen sind mir sehr
unheimlich - aber so wird objekt-orientierte Programmierung
offensichtlich meistens gelehrt, verstanden und implementiert.
"Zauberei" halt...
Warum lassen wir die Kartoffel nicht einfach was sie ist? - Ein
"Nahrungsmittel" bzw. ein "Material". Von sich aus kann diese Kartoffel
- zumindest in dem von Dir beschriebenen Kontext - ueberhaupt nichts.
Dazu bedarf es bestimmter Werkzeuge, die den Zustand der Kartoffel
veraendern koennen - und natuerlich einen Akteur, der Tools auf die
passenden Materialien anwendet - der das Messer nimmt und damit die
Kartoffel schaelt und / oder in Viertel schneidet.
Automaten koennen die zuvor entworfenen Tools (Werkzeuge) nehmen und die
Kartoffeln schaelen (lassen), Wasser und Kartoffeln in einen Topf geben,
Hitze hinzufuegen und das ganze solange kochen lassen, bis die
Kartoffeln den Zustand "gekocht" erreichen. Ein weiterer Automat koennte
aehnliches mit dem Fleisch machen (lassen). Und als letztes nimmt ein
Automat die beiden ersten Automaten, um ein (fast) vollstaendiges
Gericht zu servieren.
Mit den Automaten waeren wir dann wieder bei der prozeduralen
Entwicklung - so schlecht ist dieser Programmier-Stil nun wirklich nicht.
Wir muessen nicht jedesmal eine neue Kartoffel erfinden, nur weil wir
eine andere Art der Zubereitung oder ein neues Menue entworfen haben.
Dieses "Werkzeug Automat Material" Paradigma (WAM) stammt urspruenglich
von Heinz Zuellighoven. Wenn ich es recht sehe, ist er zwar heute der
Typ-Sicherheit wegen ein Verfechter von Java, aber seine ersten
praktischen Erfahrungen mit kommerziellen, objekt-orientierten
Software-Projekten hatte er mit SmallTalk gesammelt.
Aus meiner vereinfachten Sicht setzt der WAM-Ansatz dem im
SmallTalk-Kontext entworfenen Model-View-Controller (MVC) Paradigma
einfach noch die Krone auf.
Juergen.
Hübner, Uwe wrote:
Käme auf einen Versuch an ob das wirklich so unerträglich aussieht.
Aber man könnte noch etwas anderes machen:
Einen 'ungefähre' Farbe-Vergleich einführen.
Der würde dann True liefern wenn man von der Farbe nicht allzu
weit entfernt ist. Der müsste allerdings den Vergleich auf
Gleichheit ersetzen, sonst hat man wieder eine potentielle
Fehlerquelle.
Aber was wir definitiv nicht brauchen sind Menschen die guten
Willens sind, sich für den Einsatz der Etoys im Unterricht
interessieren und dann vor die Wand laufen.
Im Marketing gibt es die Erkenntnis, dass es deutlich einfacher ist
einen Kunden zu verlieren. Der rennt dann rum und erzählt allen wie
schlecht das Produkt ist. Aber man muss 10 Kunden begeistern, damit
es einen gibt der das weitererzählt.
Dann lieber die Etoys soweit abspecken, dass nur noch robustes
E-Zeugs übrigbleibt. Ich war zum Beispiel von der Robustheit
von Scratch total begeistert. Dabei ist Scratch vom Prinzip her
genau so aufgebaut wie die Etoys, aber die Benutzeroberfläche ist
deutlich suggestiver.
Die Version 3.9 der Etoys ist jedenfalls (soweit ich das bisher beurteilen
kann) ein Schritt (oder zwei) in die richtige Richtung.
Allerdings weiß ich nicht in wie
weit mein prozeduraler Programmierhintergrund mir hier einen Streich
gespielt hat. Aber ich denke prozedurale Sprachen sind leichter
zu verstehen weil sie nach dem Prinzip der Kochrezepte arbeiten:
1. Koche(Kartoffeln)
2. Brate(Fleisch)
3. Nachdem Gekocht(Kartoffeln) und Gebraten(Fleisch)
Serviere(Essen)
Dagegen wäre Smalltalkorientiertes kochen etwa so
(ohne wirklich viel Ahnung von Smalltalk zu haben):
Kartoffeln koche dich Fleisch brate dich
Sende Fertig Sende Fertig
Nachdem Kartoffeln Fertig
Nachdem Fleisch Fertig
Essen serviere dich
Gruß Uwe
MSC Vertriebs GmbH
registered office : Stutensee
Jurisdiction and registered Mannheim, Germany, HRB No. 10 3631
Managing Director: Manfred Schwarztrauber, Lothar Kümmerlin, Rüdiger Kuhn
Gleichmann & Co. Electronics GmbH
registered office : Frankenthal
Jurisdiction and registered Ludwigshafen, Germany, HRB No. 21305
Managing Director: Manfred Schwarztrauber, Thomas Klein
-----Ursprüngliche Nachricht-----
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Bert Freudenberg
Gesendet: Donnerstag, 10. April 2008 16:52
An: Squeak in Germany / Squeak in Deutschland
Betreff: Re: [Squeak-ev] Einfaches EToy-Projekt funktioniert nicht!
Wichtigkeit: Hoch
On 10.04.2008, at 07:30, Hübner, Uwe wrote:
Danke Bert.
Wahnsinn!
Ursprünglich war ich ja noch viel weiter und habe verschiedene Dinge
ausprobiert...
Sollte man das nicht ein wenig 'robuster' machen?
Wie soll ein armer Lehrer auf so etwas kommen?
Das einzige, was man da machen könnte, ist das Zeichnen der Konnektoren auf
"pixelig" umzustellen. Aber das will doch keiner, oder?
- Bert -