LU01.L13 - Dasselbe Problem in drei Paradigmen

noten = [('Alina', 5.5), ('Ben', 3.5), ('Chiara', 4.0), ('Dario', 5.0), ('Elif', 3.9)]
 
if __name__ == '__main__':
    summe = 0
    ungenuegend = []
    beste = noten[0][1]
 
    for name, note in noten:
        summe += note
        if note < 4.0:
            ungenuegend.append(name)
        if note > beste:
            beste = note
 
    durchschnitt = summe / len(noten)
 
    print(f'Durchschnitt: {durchschnitt:.2f}')
    print(f'Ungenuegend: {ungenuegend}')
    print(f'Beste Note: {beste}')

Drei Variablen werden parallel fortgeschrieben. Wer eine vierte Kennzahl braucht, ergänzt eine vierte Variable und eine weitere Zeile im Schleifenkörper – die Schleife wird mit jeder Kennzahl unübersichtlicher.

class Klasse:
    def __init__(self, noten=None):
        self._noten = list(noten) if noten else []
 
    def hinzufuegen(self, name, note):
        self._noten.append((name, note))     # veraendert den eigenen Zustand
 
    def durchschnitt(self):
        return sum(note for _, note in self._noten) / len(self._noten)
 
    def ungenuegende(self):
        return [name for name, note in self._noten if note < 4.0]
 
    def beste_note(self):
        return max(note for _, note in self._noten)
 
 
if __name__ == '__main__':
    klasse = Klasse([('Alina', 5.5), ('Ben', 3.5), ('Chiara', 4.0),
                     ('Dario', 5.0), ('Elif', 3.9)])
 
    print(f'Durchschnitt: {klasse.durchschnitt():.2f}')
    print(f'Ungenuegend: {klasse.ungenuegende()}')
    print(f'Beste Note: {klasse.beste_note()}')

from functools import reduce
 
 
def noten_werte(noten):
    """Loest die Noten aus den Paaren heraus."""
    return map(lambda paar: paar[1], noten)
 
 
def durchschnitt(noten):
    return reduce(lambda a, b: a + b, noten_werte(noten)) / len(noten)
 
 
def ungenuegende(noten):
    return list(map(lambda paar: paar[0],
                    filter(lambda paar: paar[1] < 4.0, noten)))
 
 
def beste_note(noten):
    return reduce(lambda a, b: a if a > b else b, noten_werte(noten))
 
 
def note_hinzufuegen(noten, name, note):
    return noten + [(name, note)]           # neue Liste statt Veraenderung
 
 
if __name__ == '__main__':
    noten = [('Alina', 5.5), ('Ben', 3.5), ('Chiara', 4.0),
             ('Dario', 5.0), ('Elif', 3.9)]
 
    print(f'Durchschnitt: {durchschnitt(noten):.2f}')
    print(f'Ungenuegend: {ungenuegende(noten)}')
    print(f'Beste Note: {beste_note(noten)}')

def durchschnitt(noten):
    return sum(note for _, note in noten) / len(noten)
 
def beste_note(noten):
    return max(note for _, note in noten)

Am einfachsten funktional: Man schreibt eine weitere unabhängige Funktion median(noten). Nichts Bestehendes wird angefasst, nichts kann kaputtgehen.

Am schwierigsten prozedural: Die neue Kennzahl braucht eine weitere Variable vor der Schleife und eine weitere Zeile darin. Die Schleife übernimmt damit noch eine Aufgabe mehr – ein Verstoss gegen das Prinzip, dass ein Codeblock für genau eine Sache zuständig sein soll.

Die OO-Fassung liegt dazwischen: Eine neue Methode ist schnell ergänzt, sie hängt aber am Zustand des Objekts.

klasse = Klasse(noten)
print(round(klasse.durchschnitt(), 3))   # 4.38
klasse.hinzufuegen('Fabio', 2.0)
print(round(klasse.durchschnitt(), 3))   # 3.983

durchschnitt() hat keine Argumente. Sein Ergebnis hängt ausschliesslich vom verborgenen Zustand self._noten ab – und der hat sich zwischen den beiden Aufrufen geändert. Der Aufruf ist damit nicht referenziell transparent: Man kann ihn nicht durch seinen Wert ersetzen, ohne die Vorgeschichte zu kennen.

In der funktionalen Fassung ist das ausgeschlossen, weil die Daten sichtbar im Argument stehen:

print(durchschnitt(noten))                          # 4.38
erweitert = note_hinzufuegen(noten, 'Fabio', 2.0)
print(durchschnitt(noten))                          # 4.38 - unveraendert
print(durchschnitt(erweitert))                      # 3.983 - andere Daten, anderer Name

Unterschiedliche Ergebnisse haben hier unterschiedliche Namen. Genau das ist der Gewinn.

Erkennbar an drei Punkten:

• hinzufuegen gibt nichts zurück (None) und tut stattdessen etwas – es ist eine Prozedur im Sinn von LU01c.
• self._noten.append(…) verändert eine bestehende Datenstruktur, statt eine neue zu erzeugen.
• Die Reihenfolge der Aufrufe entscheidet über das Ergebnis – das Kennzeichen zustandsbehafteter, imperativer Programmierung.

Objektorientierung ist also kein Gegensatz zur imperativen Programmierung, sondern eine Art, imperativen Code zu organisieren: Sie bündelt Zustand und die darauf arbeitenden Prozeduren zu Einheiten. Der Gegensatz verläuft zwischen Zustand verändern und Werte erzeugen, nicht zwischen OO und funktional.

TypeError: reduce() of empty iterable with no initial value

reduce ohne Startwert nimmt das erste Element als Anfang – bei einer leeren Folge gibt es keines. Zwei saubere Behandlungen:

# Variante A: Startwert angeben
def summe(noten):
    return reduce(lambda a, b: a + b, noten_werte(noten), 0)
 
# Variante B: den Randfall zur Bedingung der Funktion machen
def durchschnitt(noten):
    if not noten:
        raise ValueError('Durchschnitt einer leeren Notenliste ist undefiniert')
    return reduce(lambda a, b: a + b, noten_werte(noten)) / len(noten)

Bei der Summe ist 0 ein sinnvoller Startwert. Beim Durchschnitt nicht: Er wäre eine Division durch null. Und bei beste_note gibt es überhaupt keinen neutralen Startwert – hier ist Variante B die einzig ehrliche Antwort. Das ist ein guter Moment, um zu sehen, dass nicht jede Aggregation einen sinnvollen Anfangswert hat.

Mögliche Antworten – die Beispiele der Lernenden dürfen abweichen, müssen aber begründet sein:

Fazit: In der Praxis werden die drei Stile gemischt. Eine typische Anwendung hat objektorientierte Struktur an der Oberfläche, einen funktionalen Kern für die Berechnungen und prozedurale Ränder dort, wo mit Dateien, Netzwerk und Benutzern interagiert wird.

© Kevin Maurizi