Re: [Squeak-ev] Von der Kachelprogrammierung zu Smalltalk: Begründungen?

Markus Schlager m.slg at gmx.de
Don Apr 28 19:15:12 UTC 2011


Hallo Esther,

On Thu, 28 Apr 2011, Esther Mietzsch wrote:

> Meine Etoys-Schützlinge wollten noch nie, dass der Benutzer ihrer selbst
> programmierten Spiele etwas eingibt.
> Allerdings hatte ich letzens folgende Aufgabe, die ich beinahe mit "richtigem"
> Programmieren gelöst hätte: Jedesmal, wenn die Spielfigur auf ein bestimmtes
> Feld kommt, soll in der Ecke ein Monster erscheinen, das dann die Spielfigur
> verfolgt. Eigentlich klappte das ganz gut mit Klonen, aber es ist mir nicht
> gelungen, für die Klone dann wieder Kacheln zu haben, die ich hätte nutzen
> können, um die Monster z.B. individuell zu steuern. Das programmierende Kind
> hat dann großzügig auf die inidivuelle Steuerung der Monster verzichtet.
> Also, ich denke in "freier Wildbahn" findet sich immer mal was, was mit
> Kacheln halt nicht mehr geht, aber so richtig zwingend ist es dann doch nie.
> Gruß
> Esther


Das finde ich in der Tat einen guten Punkt für den Übergang 
Etoys->Smalltalk (und zwar gleich richtig mit dem Systembrowser). Ein 
großer Unterschied zwischen der Kachel- und der 'richtigen' 
Programmiererei besteht schon darin, dass man beim 'richtigen' 
Programmieren eben *Klassen* programmiert, sprich Vorlagen für 
gleichartige Objekte, von denen man mehrere haben kann/möchte. Bei den 
Kacheln dagegen hat man es nur mit Singletons/einzelnen Objekten zu tun. 
Geschwister und Duplikate sind eine Möglichkeit, so etwas Klassenartiges 
anzunähern, aber immer mit dem Haken, dass Geschwister etwa oft sehr 
synchron agieren. Das ist manchmal nicht ganz durchsichtig, vor 
allem aber für die Kachelprogrammiererei zuweilen ganz schön trickreich. 
Man bastelt da immer erst einen konkreten Prototypen, der dann hoffentlich 
serienreif ist. Beim 'richtigen' Programmieren entwirft man eher einen 
abstrakten Bauplan.

Zu deinem Problem mit der Individualisierung der Monster: Das geht mit den 
Kacheln vermutlich genauso wie klassisch objektorientiert: Wenn die 
Monster alle zur selben Klasse gehören, können sie sich nur durch ihren 
Zustand, sprich die Werte ihrer Instanzvariablen unterscheiden. 
Entsprechend bräuchten die Monster Variablen, die - je nach Position oder 
Rolle - bei jedem einzelnen Monster unterschiedliche Werte annehmen können 
(das geht bei Geschwistern). Die Skripte müssten sich dann auf diese 
Variablen beziehen - etwa mittels Fallunterscheidungen oder über 
Parameter.

Markus