Ein Objekt hat einen Zustand (die Werte seiner Attribute), ein Verhalten (seine Methoden) und eine Identität: Zwei Objekte sind verschieden, auch wenn alle Attributwerte gleich sind. Eine Klasse legt Attribute und Methoden für alle ihre Objekte fest. Der Konstruktor läuft beim Erzeugen eines Objekts und setzt den Anfangszustand. In Python heißt er $\texttt{\_\_init\_\_}$, und $\texttt{self}$ ist das Objekt, das die Methode aufgerufen hat.

$\texttt{b = Buch("Faust")}$ erzeugt ein Objekt. $\texttt{b.ausleihen()}$ sendet ihm die Nachricht $\texttt{ausleihen}$.

Eine Variable, die ein Objekt trägt, enthält nur eine Referenz, einen Verweis auf das Objekt. $\texttt{c = b}$ kopiert den Verweis, nicht das Objekt (Aliasing): Beide Namen führen zum selben Objekt. $\texttt{None}$ bedeutet „kein Objekt“, und $\texttt{None.ausleihen()}$ bricht mit einem Fehler ab. Der Operator $\texttt{is}$ prüft, ob es dasselbe Objekt ist, $\texttt{==}$ prüft Gleichheit, die eine Klasse selbst festlegen kann.

Ein Zugriffsmodifikator legt fest, wer ein Attribut oder eine Methode benutzen darf:

Kapselung heißt: Der Zustand eines Objekts ist privat, Zugriffe laufen über öffentliche Methoden. Das Geheimnisprinzip geht weiter: Nutzer kennen nur die Schnittstelle, also die öffentlichen Methoden und was sie leisten, nicht die innere Darstellung. Dann lässt sich die Darstellung ändern, etwa ein Guthaben statt in Euro in Cent speichern, ohne fremden Code anzupassen. Eine Getter-Methode liest ein Attribut, eine Setter-Methode setzt es und kann Werte prüfen, bevor sie gespeichert werden. Wer aber für jedes Attribut einen Getter und einen Setter anbietet, gibt die innere Darstellung doch preis.

Die Multiplizität am Ende einer Beziehung gibt an, wie viele Objekte beteiligt sind: $\texttt{1}$ genau eins, $\texttt{0..1}$ höchstens eins, $\texttt{*}$ beliebig viele (auch keins), $\texttt{1..*}$ mindestens eins.

In Python steht eine Beziehung als Attribut, das auf Objekte verweist, zum Beispiel $\texttt{\_buecher}$ in der Bibliothek.

Ein Klassendiagramm zeigt jede Klasse als Rechteck mit drei Fächern (Name, Attribute, Methoden) und die Beziehungen zwischen den Klassen. Einträge schreibt man als $\texttt{- verliehen : bool}$ oder $\texttt{+ ausleihen() : bool}$. Die Klasse Buch hat also $\texttt{+ titel : str}$, $\texttt{- verliehen : bool}$, $\texttt{+ ist\_verliehen() : bool}$ und $\texttt{+ ausleihen() : bool}$. Von Bibliothek führt eine Linie mit hohler Raute zu Buch, am Buch-Ende steht $\texttt{*}$.

Ein Sequenzdiagramm zeigt, in welcher Reihenfolge Objekte einander Nachrichten senden. Jedes Objekt hat oben ein Rechteck $\texttt{name : Klasse}$ und darunter eine senkrechte Lebenslinie. Die Zeit läuft von oben nach unten. Ein Pfeil zwischen zwei Lebenslinien ist ein Methodenaufruf, ein gestrichelter Pfeil zurück ist die Rückgabe.

Objekte lassen sich in einem Feld (feste Länge, Zugriff über den Index) oder einer Liste (veränderliche Länge) sammeln. Das Feld enthält Referenzen, nicht die Objekte selbst. Eine Schleife sendet jedem Element dieselbe Nachricht. Verändert man ein Objekt über die Schleifenvariable, ändert man das Objekt in der Liste, denn beide verweisen auf dasselbe.

Zwei Maße beurteilen einen Entwurf. Die Kohäsion misst, wie eng die Aufgaben innerhalb einer Klasse zusammengehören. Sie soll hoch sein: Eine Klasse hat eine klar umrissene Verantwortung. Die Kopplung misst, wie stark Klassen voneinander abhängen. Sie soll lose sein: Eine Klasse kennt wenige andere und nur deren Schnittstelle.

Eine Klasse Konto, die auch Kontoauszüge formatiert und E-Mails verschickt, hat niedrige Kohäsion, und jede Änderung am Mailversand zwingt zum Ändern von Konto. Besser sind getrennte Klassen für Konto, Kontoauszug und Mailversand. Greift eine Klasse direkt auf Attribute einer anderen zu, ist die Kopplung eng: Jede Änderung der inneren Darstellung wirkt sich dort aus.