Aufgabe 13 - Sensor-Steckplätze

Aufgabe 13 - Sensor-Steckplätze

Worum geht es?

Interfaces als Steckplätze: Eine Wetterstation akzeptiert jeden Sensor, der den Vertrag erfüllt, auch solche, die es beim Schreiben der Station noch gar nicht gab. Genau so werden externe Programmbausteine sauber integriert und eigene Bausteine anderen zur Verfügung gestellt, eine ausdrückliche Lehrplan-Kompetenz (siehe Kapitel Polymorphismus und Interfaces). Der Höhepunkt der Übung ist der Bausteintausch mit einer Kollegin oder einem Kollegen (Tauschpartner): fremder Code läuft an Ihrer Station, ohne dass Sie eine Zeile ändern.

Was Sie dafür brauchen

• Kapitel Polymorphismus und Interfaces, insbesondere abstrakte Basisklassen und Duck Typing; Aufgabe 12.
• Python (abc, random), VS Code; für Teil C eine Tauschpartnerin oder einen Tauschpartner.

Welche Kompetenzen Sie erwerben und zeigen

• Sie definieren einen Vertrag als abstrakte Basisklasse und programmieren strikt dagegen.
• Sie integrieren fremde Programmbausteine über eine Schnittstelle und stellen eigene bereit.
• Sie grenzen erzwungene Verträge experimentell von Duck Typing ab.

Pädagogische Einordnung

• Reproduktion: den Vertrag und einen einfachen Sensor nach Vorgabe implementieren (Teil A).
• Reorganisation und Transfer: weitere Sensoren entwickeln und fremde Bausteine integrieren (Teile B und C).
• Reflexion, Problemlösung und Urteilsbildung: die Grenzfälle des Typsystems untersuchen und Vertragsstrategien bewerten (Teil D).

Arbeitsaufträge

Die Übung ist auf etwa zwei Stunden ausgelegt. Teil D ist der Expertenteil.

Teil A - Vertrag und erster Sensor

1. Definieren Sie die abstrakte Klasse Sensor mit dem Attribut name, der abstrakten Methode measure() (liefert eine Zahl) und der abstrakten Property unit (etwa "°C").
2. Implementieren Sie TemperatureSensor: simuliert Werte zwischen 15 und 35 mit random.uniform, Einheit "°C".
3. Prüfen Sie: Sensor() direkt zu instanzieren schlägt fehl; der Temperatursensor liefert bei fünf Aufrufen fünf plausible Werte.

Teil B - Die Station

1. Implementieren Sie WeatherStation mit connect(sensor) und run_measurement(): fragt alle angeschlossenen Sensoren ab und druckt pro Sensor eine Zeile wie temperature: 21.3 °C. Verbindliche Regel: Die Stationsdatei importiert keine konkrete Sensorklasse, nur den Vertrag.
2. Ergänzen Sie HumiditySensor (0 bis 100, "%") und WindSensor (0 bis 120, "km/h").
3. Demo: Station mit drei Sensoren, fünf Messrunden, lesbare Ausgabe mit Rundennummer.

Teil C - Der Bausteintausch

1. Vereinbaren Sie mit Ihrer Tauschpartnerin oder Ihrem Tauschpartner nur den Vertrag (die Sensor-Klasse muss identisch sein). Jede Person schreibt zusätzlich einen eigenen, neuen Sensor nach freier Wahl (Luftdruck, Helligkeit, Lautstärke, …).
2. Tauschen Sie ausschließlich die Sensor-Datei aus. Der fremde Sensor muss an Ihrer Station laufen, ohne dass Sie irgendetwas anpassen. Protokollieren Sie das Ergebnis (funktioniert / funktioniert nicht, und warum).
3. Halten Sie in zwei Sätzen fest, was dieser Tausch mit den Lehrplan-Formulierungen “externe Programmbausteine integrieren” und “eigene Programmbausteine zur Verfügung stellen” zu tun hat.

Teil D - Expertenteil: Duck Typing und Vertragsbruch

1. Schreiben Sie eine Klasse RogueSensor, die nicht von Sensor erbt, aber zufällig passende measure()-Methode und unit-Property besitzt. Schließen Sie sie an die Station an. Läuft sie? Erklären Sie mit dem Begriff Duck Typing, warum.
2. Schreiben Sie eine Klasse, der die unit-Property fehlt, und schließen Sie sie an. Zu welchem Zeitpunkt genau tritt der Fehler auf: beim Anschließen oder erst in der Messrunde? Was bedeutet dieser Zeitpunkt für die Fehlersuche in einem großen Programm?
3. Erweitern Sie connect(sensor) um eine Eingangsprüfung mit isinstance(sensor, Sensor), die Fremdlinge sofort mit einer Meldung ablehnt. Diskutieren Sie in drei bis fünf Sätzen den Zielkonflikt: Die Prüfung macht Fehler früh sichtbar, sperrt aber auch den (funktionierenden!) RogueSensor aus. Welche Strategie wählen Sie für die Station, und warum?
4. Formulieren Sie als Abschluss eine Empfehlung in zwei Sätzen: In welchen Projektsituationen genügt Duck Typing, wann ist die abstrakte Basisklasse Pflicht?

Wissenscheck

1. Was garantiert die abstrakte Basisklasse einer Subklasse gegenüber, und wann fliegt ein Vertragsbruch auf?
2. Warum darf die Stationsdatei keine konkrete Sensorklasse importieren? Was ginge sonst verloren?
3. Erklären Sie Duck Typing in einem Satz anhand des RogueSensor.
4. Was ist der Nachteil, wenn ein fehlender Vertragsbestandteil erst in der Messrunde auffällt statt beim Anschließen?
5. Ihre Station soll nächstes Jahr Sensoren eines fremden Herstellers unterstützen. Was genau geben Sie dem Hersteller, und was verlangen Sie von ihm?

Abgabe

station.py, sensors.py, der getauschte Fremdsensor samt Tauschprotokoll und die Diskussionen aus Teil D.