Notizen · InformatikAT · Matura

INF-OOP - Programmierparadigmen und Objektorientierung

Verschiedene Programmierparadigmen (imperativ, deklarativ, funktional, objektorientiert) lösen unterschiedliche Probleme. OOP ist Standard für komplexe Anwendungen.

3Abschnitteca. 8Min Lesezeit3KompetenzenNiveauStandard 2 · Vertiefung 1Stand 06/2026

T·111111 / 12

Prüfungsprofil

INF-OOP-1 · Programmierparadigmen vergleichenINF-OOP-2 · OOP-Konzepte (Klasse, Objekt, Vererbung, Polymorphie) anwendenINF-OOP-3 · SOLID-Prinzipien und Design Patterns erkennen

Tiefe

Schrift

Inhalt · 3 Abschnitte

INF-OOP - Programmierparadigmen und Objektorientierung

Programmierparadigmen im Vergleich#

StandardINF-OOP-1.1

Ein Programmierparadigma ist eine grundlegende Denkweise, wie man ein Problem in Code fasst. Kein Paradigma ist „das beste" - sie sind Werkzeuge für verschiedene Probleme (), und moderne Sprachen mischen sie.

Programmierparadigmen im Vergleich

Abb. 1Jedes Paradigma fasst ein Problem anders; moderne Sprachen mischen sie.

Imperativ beschreibt das Wie: eine Folge von Anweisungen, die schrittweise den Zustand (Variablen) verändern - die klassische Schleifen-und-Zuweisungs-Programmierung (C, Pascal). Sie ist nah an der Maschine und intuitiv für Algorithmen.

Deklarativ dreht das um und beschreibt das Was, nicht das Wie; die Ausführung überlässt man einer Engine. SQL formuliert, welche Daten man will, der Optimizer findet den Weg; HTML beschreibt Struktur, der Browser rendert. Vorteil: Die Lösung lässt sich optimieren, ohne sie umzuschreiben.

Funktional behandelt Funktionen als First-Class-Citizens (übergebbar wie Werte), setzt auf Unveränderlichkeit (Immutability) und vermeidet Seiteneffekte (reine Funktionen) - das erleichtert Testen und Parallelisierung. Reinformen sind Haskell und Lisp; map/filter/reduce und Lambdas haben aber fast jede Sprache erreicht (Python, JS).

Objektorientiert bündelt Daten und Verhalten in Objekten (Java, C#, Python, C++) - der Standard für große Anwendungen. Logikbasiert (Prolog) beschreibt ein Programm als Sammlung von Fakten und Regeln, aus denen ein Inferenzsystem Schlüsse zieht.

Moderne Sprachen sind multiparadigmatisch: Python etwa erlaubt imperativen, funktionalen und objektorientierten Stil in derselben Datei - man wählt pro Aufgabe das passende Mittel (siehe Beispiel). Häufige Fehler: „funktional" mit „modular" gleichsetzen, JavaScript für rein objektorientiert halten, oder „deklarativ" mit „weniger Code" verwechseln.

Musterbeispiel

Imperativ vs. funktional (Python)

Quadrate aller geraden Zahlen einer Liste `[1, 2, 3, 4, 5, 6]`.

Imperativ
```python ergebnis = [] for n in [1,2,3,4,5,6]: if n % 2 == 0: ergebnis.append(n*n) ```
Funktional / Comprehension
```python ergebnis = [n*n for n in [1,2,3,4,5,6] if n % 2 == 0] ```
Funktional / map+filter
```python ergebnis = list(map(lambda n: n*n, filter(lambda n: n%2==0, [1,2,3,4,5,6]))) ```

Ergebnis: Alle drei liefern $[4, 16, 36]$ . Comprehension ist in Python idiomatisch; map/filter ist eher Lisp-Stil.

Schritt-für-Schritt Erklärung3 Schritte

1
Programmierparadigmen sind nicht Mode, sondern Werkzeuge für unterschiedliche Probleme.
2
Deklarativ trennt das Was vom Wie - dadurch lassen sich Lösungen oft optimieren, ohne sie umzuschreiben.
3
Funktionale Konzepte (map/filter/reduce, Immutability) haben heute fast jede Sprache erreicht.

SRDP-Aufgaben

SelbsttestAus der Fragenbank7 Punkte

Aufgabenstellung

Vergleiche imperative, deklarative und objektorientierte Programmierparadigmen. Nenne je eine Sprache und einen typischen Anwendungsfall.

Deine Antwortwird nicht automatisch bewertet

Typische Fehler

"Funktional" wird mit "modular" gleichgesetzt.
JavaScript wird als rein OOP eingestuft.
Deklarativ wird mit "weniger Code" gleichgesetzt.

Aktive Wiederholung

Löse das Problem "Quadrate aller geraden Zahlen einer Liste" jeweils imperativ und funktional in Python. Welche Variante ist lesbarer?

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

Quellen: Sebesta: Concepts of Programming Languages (Pearson)

Klassen, Vererbung und Polymorphie#

StandardINF-OOP-2.1

Objektorientierung strukturiert ein Programm rund um Objekte, die Daten und das zugehörige Verhalten zusammenfassen. Vier Säulen tragen das Paradigma: Kapselung, Vererbung, Polymorphie und Abstraktion.

Eine Klasse ist der Bauplan (ein Typ), ein Objekt eine konkrete Instanz davon mit eigenem Zustand. Encapsulation (Kapselung) bündelt Daten und Methoden und schränkt den Zugriff über Sichtbarkeiten (public/protected/private) ein - von außen spricht man nur die definierte Schnittstelle an, nicht die internen Felder (siehe Beispiel mit `_saldo` und Property).

Vererbung lässt eine Unterklasse Felder und Methoden einer Oberklasse übernehmen und spezialisieren (`Sparkonto extends Konto`) - sie modelliert eine „is-a"-Beziehung (ein Sparkonto ist ein Konto) und vermeidet Wiederholung ().

Vererbungshierarchie (is-a)

Abb. 2Auto, Fahrrad und Boot erben von Fahrzeug die Methode bewegen() - eine „is-a"-Beziehung.

Polymorphie bedeutet: ein Methodenaufruf, mehrere Implementierungen. Ruft man `tier.laut()` auf, entscheidet erst zur Laufzeit die tatsächliche Objektklasse, welche überschriebene Methode läuft (dynamic dispatch / Overriding). Das ist der eigentliche Gewinn von OOP: neuer Code für neue Unterklassen, ohne den aufrufenden Code zu ändern.

Abstraktion verbirgt Implementierungsdetails hinter Schnittstellen oder abstrakten Klassen - man programmiert gegen das Was, nicht das Wie. Eine wichtige Designregel ist „Composition over Inheritance": lieber Objekte aus kleineren Komponenten zusammensetzen, als tiefe, starre Vererbungshierarchien zu bauen.

Häufige Fehler: Klasse und Objekt synonym verwenden (Bauplan vs. Instanz), Vererbung missbrauchen, wo Komposition flexibler wäre, oder Polymorphie mit Operator-Overloading verwechseln.

Musterbeispiel

Klasse "Konto" mit Vererbung

Implementiere `Konto` mit Saldo und `Sparkonto(Konto)` mit Zinssatz in Python.

Basisklasse
```python class Konto: def __init__(self, inhaber, saldo=0): self.inhaber = inhaber self._saldo = saldo def einzahlen(self, betrag): if betrag <= 0: raise ValueError("Betrag positiv") self._saldo += betrag def auszahlen(self, betrag): if betrag > self._saldo: raise ValueError("Deckung fehlt") self._saldo -= betrag @property def saldo(self): return self._saldo ```
Vererbung
```python class Sparkonto(Konto): def __init__(self, inhaber, saldo=0, zinssatz=0.02): super().__init__(inhaber, saldo) self.zinssatz = zinssatz def gutschreiben_zinsen(self): self._saldo *= (1 + self.zinssatz) ```
Anwendung
```python s = Sparkonto("Maria", 1000, 0.03) s.einzahlen(500) s.gutschreiben_zinsen() print(s.saldo) # 1545.0 ```

Ergebnis: Sparkonto erbt Saldo und Methoden, ergänzt zinsabhängige Logik. Encapsulation via `_saldo` (Konvention "protected") und Property.

Schritt-für-Schritt Erklärung3 Schritte

1
OOP ist die dominante Art, grosse Systeme zu strukturieren - Klassen bilden Modulgrenzen.
2
Vererbung ist mächtig, aber gefährlich; oft ist Composition flexibler.
3
Polymorphie ist der wahre Vorteil von OOP - ein Aufruf, viele Implementierungen.

SRDP-Aufgaben

SelbsttestAus der Fragenbank7 Punkte

Aufgabenstellung

Erläutere die OOP-Konzepte Klasse, Objekt, Vererbung und Polymorphie. Implementiere eine kleine Klassenhierarchie deiner Wahl.

Deine Antwortwird nicht automatisch bewertet

Typische Fehler

Klasse und Objekt werden synonym verwendet.
Vererbung wird missbraucht, wo Composition besser wäre.
Polymorphie wird mit Operator-Overloading verwechselt.

Aktive Wiederholung

Modelliere die Klassen `Fahrzeug`, `Auto`, `Fahrrad` mit gemeinsamer Methode `bewegen()`. Zeichne ein UML-Diagramm und implementiere in Python/Java.

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

Quellen: Gang of Four: Design Patterns - Elements of Reusable Object-Oriented Software (Addison-Wesley)

SOLID-Prinzipien und Design Patterns#

VertiefungINF-OOP-3.1

Mit der Größe eines Systems wächst die Gefahr von unwartbarem „Spaghetti-Code". SOLID-Prinzipien und Design Patterns sind das gesammelte Erfahrungswissen, wie man objektorientierten Code wartbar und erweiterbar hält ().

MVC vs. MVVM Architekturmuster

Abb. 3MVC: Controller vermittelt; MVVM: ViewModel mit Datenbindung an View.

SOLID bündelt fünf Prinzipien: Single Responsibility (eine Klasse, ein Grund zur Änderung), Open/Closed (offen für Erweiterung, geschlossen für Modifikation), Liskov Substitution (ein Subtyp muss überall für seinen Basistyp einsetzbar sein), Interface Segregation (viele kleine statt einer riesigen Schnittstelle) und Dependency Inversion (gegen Abstraktionen programmieren, nicht gegen konkrete Klassen).

Design Patterns sind erprobte, wiederverwendbare Lösungen für wiederkehrende Designprobleme - die Gang of Four beschrieb 23 davon in drei Kategorien. Sie sind kein Selbstzweck, sondern ein gemeinsames Vokabular: „Wir nutzen hier ein Observer" sagt mehr als 20 Zeilen Erklärung.

Erzeugungsmuster regeln das Erstellen von Objekten: Singleton (genau eine Instanz), Factory (Objekterzeugung delegieren), Builder (komplexe Objekte schrittweise). Strukturmuster setzen Objekte zu größeren Strukturen zusammen: Adapter (Schnittstellen anpassen), Decorator (Verhalten dynamisch ergänzen), Facade und Composite.

Verhaltensmuster regeln Zusammenspiel und Verantwortung: Observer (Subjekt benachrichtigt seine Beobachter - siehe Beispiel), Strategy (austauschbarer Algorithmus zur Laufzeit), Iterator, Command und State. Darüber liegen Architekturmuster wie MVC und MVVM, die Datenlogik (Model), Darstellung (View) und Steuerung (Controller/ViewModel) trennen () - die Grundlage moderner Web-Frameworks.

Häufige Fehler: das Singleton überbeanspruchen (oft ein Anti-Pattern, weil es globalen Zustand einführt), Pattern-Namen verwechseln (Factory vs. Builder), oder die SOLID-Prinzipien als starre Gesetze statt als Leitlinien missverstehen.

Musterbeispiel

Observer-Pattern in Python

Implementiere Subject und Observer.

Subject
```python class Subject: def __init__(self): self._obs = [] def attach(self, o): self._obs.append(o) def detach(self, o): self._obs.remove(o) def notify(self, ev): for o in self._obs: o.update(ev) ```
Observer
```python class MailObserver: def update(self, ev): print("Mail:", ev) ```
Nutzung
```python s = Subject() s.attach(MailObserver()) s.notify("Neuer Kommentar") ```

Ergebnis: Subject kennt seine Observer abstrakt; neue Observer-Klassen lassen sich ohne Änderung am Subject hinzufügen (Open/Closed).

Schritt-für-Schritt Erklärung3 Schritte

1
SOLID hilft, OOP-Code wartbar zu halten - jeder Buchstabe verhindert einen typischen Fehler.
2
Design Patterns sind kein Selbstzweck, sondern Vokabular für wiederkehrende Lösungen.
MVC vs. MVVM Architekturmuster
Abb.MVC: Controller vermittelt; MVVM: ViewModel mit Datenbindung an View.
3
MVC trennt drei Verantwortlichkeiten - das macht moderne Web-Frameworks überhaupt erst beherrschbar.

SRDP-Aufgaben

SelbsttestAus der Fragenbank7 Punkte

Aufgabenstellung

Erkläre SOLID-Prinzipien an je einem Beispiel. Beschreibe zusätzlich das Observer- oder Strategy-Pattern und nenne eine Anwendung.

Deine Antwortwird nicht automatisch bewertet

Typische Fehler

Singleton wird überbeansprucht (Anti-Pattern in vielen Fällen).
Pattern-Namen werden falsch zugeordnet (Factory vs. Builder).
SOLID-Prinzipien werden als starre Gesetze missverstanden.

Aktive Wiederholung

Beschreibe das Observer-Pattern am Beispiel "Benachrichtigungen in einem sozialen Netzwerk". Welche Vorteile bietet es?

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

Quellen: Robert Martin: Clean Architecture (Prentice Hall)

Belege & Quellen

Quellen

Pearson

Sebesta: Concepts of Programming Languages