Programmieren lernen

[gilmour]

Hallo, ich würd gern lernen programme für Mac OS X zu programmieren. Ich habe noch nie programmiert. Und wollt wissen was man dafür alles lernen muss und ob es nützliche Internet seiten oder Bücher dazu gibT?

 

[Kwoth]

Mein Tipp:



Objective-C und Cocoa. Von Klaus M. Rodewig (Autor), Amin Negm-Awad (Autor)

 

[tommy]

Hallo,

ja auf alle Fälle http://developer.apple.com/de dort kannst Du auch xCode kostenlos downloaden. Ebenfalls findest Du da auch verschiedene Referenzen zu den Frameworks.

Jetzt solltest Du erst einmal überlegen was Du später einmal programmieren möchtest. Mehr Web-Programmierung oder Systemprogrammierung? Für System steht da ganz klar Objective-C und C/C++ ganz oben. Objective-C hat etwas an Abschreckung, da es für Anfänger absolut nicht ganz klar ist als bei C99.

Java bietet einen schönen Einstieg und nimmt Dir auch die Speicherbereinigung ab. Man kann damit "fast alles" anstellen, nur etwas langsamer. Gleicht aber die Entwicklungszeit wieder aus.

Objective-C schöne native Anwendungen mit Cocoa
Java der Alles-könner (andere Frameworks -> auch Java: z.B.: QT)
C/C++ siehe Obj-C nur das man auch andere Frameworks nutzen kann

Wenn Du also Software portieren willst nimm Java. Als Einsteiger wirst Du es auch schwerer bei Objective-C haben, da es weniger Material dazu gibt. Zwei drei deutsche Bücher gibt es auf dem Markt im 30-50 Euro Bereich.

Nun dann viel Spaß bei Deinem Vorhaben
Probiere ruhig etwas rum was Dir mehr gefällt. Das erste muss nicht gleich das beste sein!

Gruß, Tommy

edit:
AppleScript gibt es noch, aber nicht gerade für große Dinge. Ansonsten noch Ruby, Perl, TCL und ein paar andere Konsorten. Viel halte ich aber davon nicht im GUI Bereich.

 

[gilmour]

Java bietet einen schönen Einstieg und nimmt Dir auch die Speicherbereinigung ab. Man kann damit "fast alles" anstellen, nur etwas langsamer. Gleicht aber die Entwicklungszeit wieder aus.

Du meinst also Java wäre am besten als Einstieg. Gibts da irgendwelche Internet seiten wo man als anfänger was lernen kann oder empfelens werte bücher für anfänger für Java?

 

[Bier]

Java ist ja auch so leicht... klar. Ich würd ja gleich mit Bytecode anfangen... ah neh, Java funktioniert ja schon auf der Ebene. Hmmh, was nehmen wir dann: Marbolge?

Programmieren kann man nicht mit einer _Sprache_ lernen. Ich lerne schließlich Sprechen, dann inhaltsbezogene Sätze bilden. Eine Sprache eignet sich so was von schlecht zum Erlernen von Programmierkonzepten...
Pseudo-code, algorithmisch orientiert, möglichst C-nah. Dann die Prinzipien wie Schleifen, Methoden, OOP lernen. Dann erst eine Sprache. Anders geht das sowieso nicht. Wäre ja auch recht verwunderlich wenn man loslegen könnte mit Objective C... Nach dem Motto: was wir nicht können, kann für uns das Framework. Herrliche Idee.

 

[tommy]

Du meinst also Java wäre am besten als Einstieg. Gibts da irgendwelche Internet seiten wo man als anfänger was lernen kann oder empfelens werte bücher für anfänger für Java?

http://www.galileocomputing.de/openbook/javainsel7/

Das gibts von Galileo auch in der C Version. http://pronix.de mit einer speziellen Linux Ausgabe. Irgendwo liegt auch eine Win-API Ausgabe rum.

Mit Java wirst Du auf jedenfall schnell Erfolge haben, da alles "da ist von Haus aus". Ich habe damals mit Assembler angefangen, die einzigste Quahl...

Wäre ja auch recht verwunderlich wenn man loslegen könnte mit Objective C... Nach dem Motto: was wir nicht können, kann für uns das Framework. Herrliche Idee.

Objective-C ist da eh der falsche Kandidat :-D Diese + und - haben mich anfangs völlig konfus gemacht, und erst diese Klammern [] erinnern mich mit grauen an TCL.

 

[tfc]

Wenn man noch nie programmiert hat, dann ist Python oder Ruby wohl eine bessere Wahl.

Wenn man damit schon ein paar Anwendungen geschrieben hat, dann muss man sich beim Umstieg auf eine der C-Sprachen zwar schwer umerziehen, was das Handling mit Datentypen angeht, aber das ist leichter hinzukriegen, wenn man mit Programmierung allein vertrauert geworden ist.

 

[below]

Objective-C ist da eh der falsche Kandidat :-D Diese + und - haben mich anfangs völlig konfus gemacht, und erst diese Klammern [] erinnern mich mit grauen an TCL.

Die Syntax von Objective-C verfolgt aber das Ziel, natürliche Sprache nachzubilden:

[Lisa wirf:[ball mitDerFarbe:rot] zu:Tom];

ist gültige Objective-C Syntax

Alex

 

[tommy]

Die Syntax von Objective-C verfolgt aber das Ziel, natürliche Sprache nachzubilden:

[Lisa wirf:[ball mitDerFarbe:rot] zu:Tom];

ist gültige Objective-C Syntax

Alex

Ein C Verwöhnter "Tom getBall(Lisa)" finde ich ist anfangs logischer. Diese Klammern können leicht etwas komplexer erscheinen lassen als es wirklich ist. Daher finde ich OBJ-C für den Einstieg unpassend. Aber wer ins kalte Wasser fällt, ja der lernt schwimmen :-D

 

[Zettt]

Mal so nebenbei...

Pseudo-code, algorithmisch orientiert, möglichst C-nah. Dann die Prinzipien wie Schleifen, Methoden, OOP lernen. Dann erst eine Sprache. Anders geht das sowieso nicht. Wäre ja auch recht verwunderlich wenn man loslegen könnte mit Objective C... Nach dem Motto: was wir nicht können, kann für uns das Framework. Herrliche Idee.

Hast du vielleicht ein paar Online-Resourcen wo man sich bisschen in das Thema OOP einpfriemeln kann? Irgendwie tu ich mich da doch noch ziemlich hart.
Auch das mit den Klassen hab ich noch nicht ganz verstanden

 

[tommy]

darüber gibt es ganze Bücher, aber ein paar C++ und Java Bücher greifen das ganz gut auf. Kostenlos "Java ist auch eine Insel" von Galileo, oder Java Core von Sun. Allerdings kosten die beiden Bücher um die 100 Euro im Set.. also solltest Du Dir das überlegen.

Aber was verstehst Du an den Klassen nicht, vielleicht kann man Dir da ja eine Erleuchtung bringen? Achja, bist Du nun bei Java, Objective-C oder ganz wo anders gelandet? Das Prinzip ist eigentlich immer gleich. Nur das optische ist manchmal anders

http://www.complang.tuwien.ac.at/franz/objektorientiert/skript07-1seitig.pdf
Wenn Du etwas mit C oder PHP...(ohne OOP) programmierst und keine Klassen hast wirst Du vielleicht schneller hinter der Wertschätzung kommen Software Komponenten wieder zu verwenden. Anfangs fand ich Klassen totalen Overhead, und habe C++ auch aus dem Grund hingeschmissen. Ging ja alles toll mit C. Doch irgendwann hat man das Rad 50 x erfunden, und dann fragt man sich obs nicht auch besser geht und schaut neidisch zu Java

interface AdapterInterface {
public void call();
}

class Adapter {
public Adapter(AdapterInterface a) {
a.call();
}
}

// nun die C Version
void (*myfunc)();
myfunc = dlsym(....);

// so hier ist auch schon Ende! Du kannst jetzt nicht einfach so die Sachen austauschen.
// Mit Java erstellst Du einfach eine Klasse, Grundlage dafür ist dann die Schnittstelle.
// Beispiel: Chef sagt wir nehmen HTML, seine Frau sagt morgen nein wir nehmen auch XML. Leite die Klassen einfach ab und schon kommst Du nicht in Teufelsküche. MAn hat jetzt die Wahl ob XMl HTML oder weis der Kuckuck was.

Mit C könnte man jetzt nicht einfach ein Objekt zurückgeben bei der call Methode was 2-3 Funktionen hat. Man könnte zwar eine Zeichenkette oder Ganzzahl oder Funktion zurückgeben, aber nie 2. Ausnahme wäre eine Struktur, nur ist 1 Zeiger auch nur falsch rasselt das ganze Programm nach sys_exit

 

[Zettt]

Naja gehoert ja eigentlich nicht zum Thread aber na gut.

Also bisher habe ich noch nicht verstehen koennen was Klassen genau sind. Vielleicht fehlt mir da mal ein konkretes praktisches Beispiel.

Ich lese gerade "Objective-C und Cocoa" darin werden natuerlich auch staendig neue Klassen erstellt.
Nur frag ich mich auch immer "Wieso, warum, weshalb?"

Befreundete Programmierer wenn man fragt bekommt man meist folgende Antwort:

Ein Klasse ist was ganz einfaches. Schau, du machst dir meinetwegen eine Klasse Auto. Holst du dir diese Klasse rein hast du also die Instanz eines Autos. Das Auto hat gewisse Eigenschaften Farbe, Groesse, PS. Jedes instanziierte Auto hat dann eben die Farbe rot, ist 1,50 gross und hat 200 PS.
Darueber hinaus koennen Klassen voneinander erben. Beispielsweise kannst du aus der Klasse Auto ein Motorrad ableiten indem du vorhandene Eigenschaften von Auto (4 Raeder) ueberschreibst mit Mottorrad (2 Raeder).

Das ist nicht das Problem. Das hab ich schon verstanden Klasse klasse und so. Nur irgendwie weiss ich in der Praxis wenn ich vor, sagen wir, einem Ruby Skript sitze nie wann es jetzt an der Zeit ist eine Klasse zu definieren.
Ist das verstaendlich oder Bloedsinn?

EDIT:
Das verlinkte PDF ist ganz gut. Danke
Versteh ich das richtig, dass ich eine Klasse immer dann erstelle, wenn ich eine gewisse Sammlung von Methoden zusammenfuehren moechte? (Im Sinne von einheitlich machen) Oder greift ist das in Wahrheit noch weiter?

 

[tommy]

Man sollte keine Wollmilchsau-Klassen erstellen. Wie ichs oben versucht habe zu erklären, die Klassen sollten wiederverwendbar sein. Ob man nun eine Klasse unbedingt für einen einfachen Ping in C++ anlegen muss, ist wohl jedem selbst überlassen. In Java muss man es eben.. egal obs eben ein Hello-World ist.

Der Sinn kommt bei größeren Projekten, wenn man wirklich 2 Varianten zur Auswahl geben möchte.
Datenbank oder eine Datei im FS für die Konfiguration.
Beispiel 2 wäre ein Fenster mit dem WinAPI und C++. Um nicht ständig 120 Codezeilen für 1 Fenster zuzuschreiben haust Du >>wiederverwendbar<< alles in Klassen. Danach kann man z.B. Buttons hinzufügen über eine Liste... usw.

edit:
Wichtig wäre da der Aspekt der Vererbung. Deine Fensterklasse sollte also vererbar sein, dass man Dinge hinzufügen kann ohne wieder von vorn anzufangen. Wäre ganz ideal wenn der Sourcecode verschlossen ist, sonst guckt man in die Röhre.

Bei PHP fange ich ohne OOP gar nicht erst an. Ein Freund von mir findet das total verrückt. Naja, bis jetzt konnte ich ihm noch nicht zu Klassen überreden, wobei das in PHP 5 ja nicht schlecht ist.

Darueber hinaus koennen Klassen voneinander erben. Beispielsweise kannst du aus der Klasse Auto ein Motorrad ableiten indem du vorhandene Eigenschaften von Auto (4 Raeder) ueberschreibst mit Mottorrad (2 Raeder).

Overloading könnte man bei der Vererbung dann mit einordnen. Gefällt Dir etwas nicht an der Mutterklasse überschreibst Du es einfach. Tja bei normalen C,Perl(..) Funktionen ist es schon wieder nervig.. austauschen!

 

[Zettt]

Achso.

Das steht auch in diesem PDF, dass man eben mit einer Klasse nur das "interface" anderen Programmierern zeigen muss, damit diese auf die Klasse zugreifen koennen. Die Klasse macht dann eben irgendwas bestimmtes - was verborgen ist.
Wichtig ist nur, dass man dadurch Fehler leichter aufspueren kann, wenn man zur Laufzeit feststellt es gibt an dieser oder jenen Stelle Probleme, dann liegt das wohl an der Klasse sowieso und der Methode x.
Und der Code wird natuerlich wiedervendbar. Da hast du Recht.

Klar keine Wollmilchsau, sonst geht das Argument der Fehlersuche ja wieder in Sack.
Man buendelt also gewisse Funktionen eines Programmes zu einer Klasse?!

OOP in PHP? What?

 

[tommy]

klar schon seit PHP4.. mit der 5 kamen Konstruktoren/Dekon. dazu, und natürlich public, private sowie Schnittstellen und ein paar andere Dinge. Die neueren Frameworks sind ja auch objektorientiert.

Man sollte auch darauf achten mit den Variablen, beispielsweise man hat "public String Content" nun kommt ein kluger Kopf auf die Idee das die Variable Content kein String-Objekt mehr ist sondern XmlString. Falscher Typ -> geht nicht zu kompilieren..

Abhilfe wäre damit

void setContent(String content);
void setContent(XmlString content)

oder eine Template Klasse Layout<XmlString> l;
l.setContent(DomObject); // du weist aber nicht welche Methoden die Klasse hat. Außer in PHP da geht das :-D ansonsten Reflection

 

[Amin Negm-Awad]

[…]
Aber was verstehst Du an den Klassen nicht, vielleicht kann man Dir da ja eine Erleuchtung bringen? Achja, bist Du nun bei Java, Objective-C oder ganz wo anders gelandet? Das Prinzip ist eigentlich immer gleich. Nur das optische ist manchmal anders
[…]

Nein, das Prinzip ist nicht immer gleich. "Es gibt Klassen und es gibt Instanzen" ist viel zu kurz gedacht. Genau genommen interessiert sich Objective-C gar nicht um Klassen. Sie sind eine Programmierhilfe, aber zur Laufzeit unbedeutend. Das ist definitiv ein anderes Prinzip als etwa in C++.

Ich lese gerade "Objective-C und Cocoa" darin werden natuerlich auch staendig neue Klassen erstellt.
Nur frag ich mich auch immer "Wieso, warum, weshalb?"

Jepp, das ist ein Problem: Die meisten Leute verstehen recht schnell, was eine Klasse ist. Dabei konzentrieren sie sich jedoch zu sehr auf die Funktion als Typ. Der Grund dürfte darin liegen, dass etwa in C++ eine Klasse auch nur ein Typ ist.

Warum also?
Eine Klasse ist ja die Vorlage einer Verbindung von Code und Daten zu einer Einheit. Sie kann damit als Vorlage dienen. Das erleichtert die Programmierarbeit, hat aber erst einmal nichts mit OOP zu tun. Ganz morderne Programmiersprachen verzichten ganz auf Klassen (Prototypes).Die richtige Frage lautet: Wozu Objekte?

Damit kannst du funktionale Module deiner Applikation strukturieren. Nimm ein Textfeld-Objekt. hier werden die User-Eingabe, Farben, Ränder usw und der Code, der Tastendrücke verwaltet zu einer Einheit. Wie machst du das ohne Objekte?

Du fängst dann an ein Objekt zu erstellen, wenn du eine Funktionseinheit in deinem Programm hast. Schau dir etwa Absolute Beginners an: Es wird ein Umrechnungsobjekt programmiert. Wieso? Weil Umrechnen eine funktionale Einheit der Applikation ist.

Weil ich so ein Umwandlungsobjekt habe, muss ich mir eine Umwandlungsklasse programmieren, die ich dann instantiere.

 

[Amin Negm-Awad]

Achso.

Das steht auch in diesem PDF, dass man eben mit einer Klasse nur das "interface" anderen Programmierern zeigen muss, damit diese auf die Klasse zugreifen koennen. Die Klasse macht dann eben irgendwas bestimmtes - was verborgen ist.
Wichtig ist nur, dass man dadurch Fehler leichter aufspueren kann, wenn man zur Laufzeit feststellt es gibt an dieser oder jenen Stelle Probleme, dann liegt das wohl an der Klasse sowieso und der Methode x.
Und der Code wird natuerlich wiedervendbar. Da hast du Recht.

Klar keine Wollmilchsau, sonst geht das Argument der Fehlersuche ja wieder in Sack.
Man buendelt also gewisse Funktionen eines Programmes zu einer Klasse?!

OOP in PHP? What?

Die Wiederverwertbarkeit ist zwar ein ganz gerne genommenes Argument, stimmt aber nicht. Der Code wäre exakt ebenso wiederverwertbar, wenn man ein klassisches C-Modul hätte, welches ein paar Namenskonventionen folgt und außerdem immer einen Parameter self oder this hat.

Der Unterschied liegt in der Kapselung und dort auf logischer Ebene: Ein Objekt ist eine gekapselte Einheit. Es hat Türen zum Betreten, es lässt sich im Ganzen herstellen, es lässt sich im Ganzen referenzieren, kopieren usw. Es kommt auf die Denke an: Das ist eine Einheit. Denke sie auch als Einheit.

Klassen sind nicht notwendig und dienen nur zur Programmiererleichterung. Wie gesagt: Man kann ohne Not auf Klassen verzichten.
+++
Um auf die Ausgangsfrage zurück zu kommen: Du erstellst ein Objekt, wenn du ein "Ding" in deinem Programm abbilden willst. Einen Text, einen Button, eine Maschine usw.

 

[Zettt]

Ich fasse mich mal kurz, weil ich gerade keine Frage mehr erwidern kann:

Achsooo und dankeschoen!

Mir ist gestern abend noch gekommen, dass das im Buch ja eigentlich auch ganz gut erklaert wird, einem aber halt nicht so ins Gesicht springt. Ich denke mal das liegt daran, dass "Objective-C und Cocoa" kein Buch ist was sich ausschliesslich mit OOP und Klassen allgemein beschaeftigt.

 

[hanebambel]

Hi!

Hab auch noch ne Buchempfehlung bezüglich OOP:
http://www.galileocomputing.de/openbook/oo/
Liest sich IMHO ganz gut und ist eben Praxisnah...

CU Jan

 

[Amin Negm-Awad]

Ich fasse mich mal kurz, weil ich gerade keine Frage mehr erwidern kann:

Achsooo und dankeschoen!

Mir ist gestern abend noch gekommen, dass das im Buch ja eigentlich auch ganz gut erklaert wird, einem aber halt nicht so ins Gesicht springt. Ich denke mal das liegt daran, dass "Objective-C und Cocoa" kein Buch ist was sich ausschliesslich mit OOP und Klassen allgemein beschaeftigt.

In dem Buch ist das nur deshalb so "leicht" erklärt, weil es einfach gemacht wird. Man kann da wunderbar theoretisieren. Klar. Man muss es aber häufig nicht, wenn man nicht Sprachdesigner ist. Und viele Bücher wollen mit Theoriewissen protzen. Hilft's dem Leser?

In der nächsten Auflage ist das "Wie entstand OS X"-Kapitel durch ein Einführungskapitel in OOP ersetzt worden, aber sehr bezogen auf Objective-C. Es wird auch nicht theoretisiert, sondern erläutert warum man das überhaupt braucht, als anwendungsbezogen. Dabei gehe ich übrigens von Nachrichten aus, komme zu Objekten und erst dann zu Klassen. Mal eine (unlektorierte und unformatiert, aber ich denke man sieht die "Einrückungen" am Text.) Leseprobe ohne Bilder.

Objective- …
Die Programmiersprache mit der wir hier programmieren werden, nennt sich Objective-C. Das steht ja auch auf dem Buchdeckel. Daher hier ein paar einleitende Worte zur Sprache und ihren Konzepten:
Bei Objective-C handelt es sich um eine so genannte objekt-orientierte Sprache. Die Technologie bezeichnet man als objekt-orientierte Programmierung (OOP). Da der Begriff eine ganze Zeit ein Modewort war, ist er leider versaubeutelt worden. Objective-C verdient jedoch den Namen OOP so, wie er ursprünglich von Alan Kay Ende der 70er-Jahre erfunden wurde, als er die Programmiersprache Smalltalk-80 entwickelte, den Vorläufer von Objective-C.
Kay arbeitete am Xerox Palo Alto Research Center (Xerox-PARC). Richtig, Xerox-PARC, das war das Forschungsinstitut, von der auch Apple die ersten Ideen für eine graphische Benutzeroberfläche bekam. (Später arbeitete übrigens Kay eine Zeit lang für Apple.) Und diese Idee der graphischen Benutzeroberfläche revolutionierte nicht nur die Bedienung von Computer, sondern auch ihre Programmierung. Denn für diese neue Art des User-Interfaces waren bisherige Programmiersprachen unbequem. Um das zu verstehen muss man sich erinnern (wenn man alt genug ist) oder lernen, wie man damals mit Computern arbeitete:
Grundsätzlich gab das Programm dem Benutzer in einem Raster vor, was wann zu tun war. Wir schreiben gleich ein Umrechnungsprogramm. Eine Sitzung mit einem solchen Programm hätte damals mutmaßlich wie folgt ausgesehen:
Geben Sie den Ausgangswert ein: 3[Enter]
Geben Sie den Umrechnungsfaktor ein: 2.54[Enter]
Das Ergebnis ist 7,62
Möchten Sie noch eine Umrechnung vornehmen (j/n):n[Enter]
Hier werden also 3 Zoll in 7,62 cm umgerechnet. Der Punkt ist, dass das Programm vorgibt, wann was getan wird.: Ausgangswert eingeben – Umrechnungsfaktor eingeben – Ergebnis berechnen und ausgeben – Programmende abfragen. Das Programm hat also gewissermaßen vier Arbeitsschritte, die im festen Raster abgearbeitet wurden.
1. CV_Document_Umrechnung
Eine moderne Anwendung legt Sie nicht fest.
Stellen Sie sich mal eine Anwendung für OS X vor: Hier gäbe es zwei Felder zur Eingabe der Werte (Ausgangswert und Umrechnungsfaktor), einen Button oder einen Menüeintrag Umrechnen und einen Menüeintrag Beenden. Und für Sie wäre es völlig klar, das sie jeder dieser Arbeitsschritte in beliebiger Reihenfolge ausführen können. So könnten Sie etwa den Umrechnungsfaktor 2,54 vor dem Ausgangswert eingeben. Sie könnten jederzeit das Programm beenden. Natürlich würden sie ganz häufig beim zweiten Mal nur noch den Ausgangswert eingeben und auf Umrechnen klicken, da sich der Umrechnungsfaktor nicht ändert, wenn Sie etwa eine ganze Zahlenkolonne von Zoll nach cm umrechnen. Wieso jedes Mal den Umrechnungsfaktor neu eingeben? Dann wäre also die Reihenfolge der Arbeitsschritte wieder eine andere.
Lange Rede kurzer Sinn: Mit der Erfindung der graphischen Benutzeroberfläche gibt nicht mehr das Programm die Abfolge Ihrer Arbeitsschritte vor, sondern der Benutzer dem Programm. Die Leute, die die graphische Benutzeroberfläche entwickelten nannten diesen ersten Lehrsatz: »Don’t mode me!«, übersetzt vielleicht: »Zwinge mich nicht dazu, eine bestimmte Abfolge einzuhalten.“
Und dies war für bisherige Programmiersprachen unbequem zu formulieren. Grundsätzlich denkt man beim Programmieren in Schritten, die nacheinander ausgeführt werden. Als Gleichnis werden hier gerne Kochrezepte herangezogen: Ein Arbeitsschritt nach dem anderen. Sie kämen ja auch nicht auf den Gedanken, zuerst die Pizza zu belegen und dann den Teig zu machen? Geht irgendwie nicht …
Nachrichten
Versetzen wir uns also in Kays Situation: Er kannte Programmiersprachen, die eine feste Abfolge von Arbeitsschritten wollten und er hatte im Nebenzimmer Gestalter sitzen, die sagten, dass der Benutzer eine freie Abfolge von Arbeitsschritten will. Und er musste das irgendwie zusammenbringen.
Der erste Schritt zur Lösung besteht darin, die Aktionen des Benutzers (Drücken einer Taste, Klicken auf einen Button oder einen Menüeintrag usw.) als Nachricht des Benutzers an das Programm aufzufassen. Schauen Sie sich oben noch einmal den Ablauf eines »herkömmlichen« Programmes an: Dort schickt das Programm Nachrichten an den Benutzer, was er jetzt zu tun hat. Jetzt machen wir es genau umgekehrt: Wir schicken Nachrichten an das Programm, was es zu tun hat. Also etwa: »Taste gedrückt: 3.«
Jede dieser Nachrichten wird dann vom Programmierer ein Stück Programm zugeordnet. Also, es gibt etwa ein Programmteil, der ausgeführt wird, wenn eine Nachricht »Taste gedrückt: 3« eintrifft wird der Programmteil tasteGedrückt: ausgeführt.

Für die OOP im Sinne von Kay ist die Nachricht zentral. Es gibt auch Programmiersprachen, die Nachrichten gar nicht explizit kennen. Sie sind nicht objekt-orientiert in Kays Sinne. Den Unterschied, der sich daraus ergibt, bespreche ich im Kapitel für C++-Programmierer
Objekte
Jetzt gibt es da aber ein Problem: Wohin mit der 3? Die könnte ja im ersten Eingabefeld (Ausgangswert) oder im zweiten Eingabefeld (Umrechnungsfaktor) gedrückt worden sein. Und was soll mit der 3 geschehen? Sie muss ja irgendwie in den bereits bestehenden Text im Eingabefeld angehängt oder eingefügt werden oder was auch immer.
2. EG_Nachricht
Erhält ein Objekt eine Nachricht, so führt es ein kleines Stück Programm aus
Hier kommt das zweite Konzept zum Tragen: Jede Nachricht hat einen Adressaten. Und diesen Adressaten nennt man Objekt. In unserem Beispiel wäre jedes Eingabefeld ein Objekt, eben ein Eingabefeld-Objekt. Und so ein Objekt zeichnet sich durch zwei Dinge aus: Zum einen kann es aufgrund einer Nachricht ein bisschen Programm ausführen, wie bereits oben angedeutet. Man bezeichnet dieses bisschen Programm als Methode. In unserem Beispiel könnten die beiden Objekte also die Methode tasteGedrückt: ausführen. Dort wäre dann ein bisschen Programm, welches die Taste entgegen nimmt und in den Text einfügt.
Das Zweite ist, dass ein Objekt Daten speichern kann. Nehmen Sie an, dass im ersten Eingabefeld schon der Wert 7 steht, im zweiten 2,5. Dies bedeutet, dass das erste Eingabefeld-Objekt den Wert 7 gespeichert hat und das zweite den Wert 2,5.
Um dies gleich klarzustellen: Jedes Objekt kann mehrere Werte speichern, nicht nur einen. In unserem Beispiel benötigen wir jedoch lediglich einen. Andere Werte, die zu einem Eingabefeld-Objekt gespeichert sind, sind etwa die Textfarbe (fast immer schwarz), ob ein Rahmen vorhanden ist usw.
Wird jetzt eine Taste im ersten Eingabefeld gedrückt, so erhält dieses erste Eingabefeld-Objekt die Nachricht »tasteGedrückt: 3« und führt daraufhin seine Methode tasteGedrückt: aus. Daraufhin fragt es sich selbst, welcher Wert den bisher gespeichert ist und erkennt 7.
3. EG_Objekt
Jedes Objekt kennt zudem seine Werte
An diese 7 hängt es die 3 an und speichert 73 als neuen Wert.
Drückt der Benutzer demgegenüber die Taste, während der Cursor im zweiten Eingabefeld ist, so erhält das zweite Eingabefeld-Objekt die Nachricht »Taste gedrückt: 3« und führt die Methode tasteGedrückt: aus. Dort sieht die Methode, dass bisher der Wert 2,5 gespeichert ist, hängt eine 3 an und speichert das wieder als Wert 2,53.
Wieso machte das Kay auf diese Weise? Nun, wenn wie früher das Programm die Arbeitsschritte festlegte, konnte es keine Missverständnisse geben: Der erste Wert, der vom Benutzer eingegeben wurde, war der Ausgangswert. Der zweit Wert der eingegeben wurde, der Umrechnungsfaktor. Die Zuordnung der Benutzereingabe zu den Speicherstellen des Programmes war also fest. Jetzt jedoch ging das ja alles durcheinander. Und daher musste eine Zuordnung der Nachricht und des Speichers erfolgen.
Also, zusammengefasst: Ein Objekt ist eine Einheit, die Daten speichern kann und aufgrund einer Nachricht eine Operation (Methode) ausführt.

Und man sieht schon: Das würde für C++ nicht so stimmen. Aber Kay hatte ja auch seine eigene Meinung zu C++ …