steht für objektorientiertes Programmieren und war die Revolution (!) in der Software-Erstellung der letzten 30 Jahre! Unser Objekt ist ein Bankkonto, und ein Bankkonto hat bestimmte Eigenschaften (welche?). Damit nicht genug: auf einem Bankkonto kann man bestimmte Aktionen ausführen (welche?). Man packt beides -Eigenschaften & Aktionen- zusammen in einer Vereinbarung, die man sich als Schablone vorstellen kann: alle Bankkonten werden nach diesem Muster "konstruiert", beim Menschen entspricht diesem Bauplan so in etwa die DNS (?!?). Damit man mit den Namen nicht durcheinander kommt, hat man sich fur die Vereinbarung eines Bankkontos den Begriff "Klasse" ausgedacht, unsere Aufgabe wird es also später sein, bestimmte Klassen zu programmieren. Und wenn wir ein richtiges Bankkonto benutzen, so ist das eben ein Objekt. Beachte: einzahlen kann man nur auf das Objekt Bankkonto (warum?), in der Klasse steht nur, wie's geht (die Vereinbarung).
Für die Klassen gibt es eine grafische Notation, mit der man kurz & knapp die Eigenschaften & Aktionen (=Handlungen) darstellen kann (denke an Struktogramme). Wo wir schon bei Begriffen sind: statt Eigenschaften sagt man auch Attribute, und statt Aktion benutzt man auch die Begriffe "Methode" oder "Handlung".
Bleibt mir nur noch folgender Hinweis: OOPs ist grundlegend wegen der sogenannten Vererbung. Das kann man durchaus wörtlich nehmen: wenn sich bestimmte Klassen bewährt haben (→ Fenster!), so erfindet man das Rad nicht mehr neu, sondern vererbt einfach bestimmte Eigenschaften & Methoden an eine Unterklasse und passt da & dort etwas an, fertig!
Worin könnte der Vorteil dieser Vorgehensweise liegen?
________________________________________________________________
________________________________________________________________
Sinnvolle Eigenschaften könnten z. B. der Kontostand (!) sein. Welche Aktionen kann man mit einem Bankkonto anstellen? Man kann Geld einzahlen oder abheben, oder man kann ein Konto einrichten.
In Python gibt es hierfür die class
-Vereinbarung. Die Methoden programmieren
wir direkt (?), die Eigenschaft Kontostand wird dagegen in einer speziellen
Methode vereinbart, der sogenannten __init__
-Methode:
class Bankkonto:
"""Einfache Bankkonto-Klasse"""
def __init__(self,startbetrag):
"""Konstruktor: erzeugt Bankkonto"""
self.kontostand = startbetrag
def einzahlung(self, betrag):
self.kontostand = self.kontostand + betrag
def auszahlung(self, betrag):
self.kontostand = self.kontostand - betrag
def anzeigen(self):
print self.kontostand
Beachte die Einrückungen! Zur Erklärung:
class Bankkonto
: Hier beginnt die Klassenvereinbarung, class
ist ein Python-Schlüsselwort, ähnlich wie def
oder for
. Danach kommt der Name der Klasse, hier also Bankkonto
sowie der Doppelpunkt! __init__
. Der Konstruktor erzeugt beim Aufruf ein Objekt vom Typ Bankkonto, Beispiel: konto1 = Bankkonto(100)
konto1
ist ein Objekt der Klasse Bankkonto, der Konstruktor wurde bei der
Vereinbarung eben versteckt (implizit) aufgerufen, und dabei wurde die
Variable self.kontostand
auf den Wert 100 gesetzt. Das kann man wie folgt
überprüfen:konto1.anzeigen()
# Ausgabe: 100konto1
gehört. Wenn ich also mehrere Konten vereinbare, muss (!) der Kontostand eine Eigenschaft des jeweiligen Bankkontos sein! Das erreicht man
mit der Schreibweise self
, die gerade unser jeweilges Bankkonto bezeichnet,
im Beispiel also konto1
. Damit nicht genug: ich muss ja auch den Methoden
sagen, auf welchem Bankkonto sie aus- oder einzahlen sollen, und das erreiche
ich mit dem Parameter self
.konto1.anzeigen()
.konto1.einzahlung(4711)
bzw.konto1.auszahlung(123456789)
Hier eine Beispielsitzung in IDLE:
>>> dir (Bankkonto)
['__doc__', '__init__', '__module__', 'anzeigen', 'auszahlung', 'einzahlung']
>>> konto1.anzeigen()
100
>>> konto1.einzahlung(200)
>>> konto1.anzeigen()
300
>>> konto1.auszahlung(20000)
>>> konto1.anzeigen()
-19700
>>> konto2 = Bankkonto(200)
>>> konto2.anzeigen()
200
>>> print konto1.__doc__
Einfache Bankkonto-Klasse
findest du unter dem Link Beispiele:
transfer
mit folgender Signatur (??): def transfer(self,betrag,konto):
→ sp, , 2016-12-09