Übungsaufgaben zu Clean Code: Code Smells, Werte, Kopplung und Kohäsion

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „Clean Code: Code Smells, Werte,
Kopplung und Kohäsion“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/clean-code
- https://oer-informatik.de/lesbarer-code
- https://oer-informatik.de/teststrategie
- Stilbeispiel: https://oer-informatik.de/clean-code-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Clean Code
- Code Smell
- Kopplung
- Kohäsion
- Code-Review
- KI-Assistent

Kompetenzstufe: Basiskompetenz (alternativ: Kernkompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Je richtig benanntem Smell mit passender Stelle 2 Punkte (1 Punkt für den Smell, 1 Punkt für die Stelle), höchstens 8 Punkte. Andere stichhaltige Smells (z. B. öffentliche Attribute, Rückgabe nur als Wahrheitswert) zählen ebenfalls.

Je richtiger Zuordnung 1 Punkt.

1. Wandelbarkeit: Änderungen an einer Regel sollen nur eine Stelle betreffen.

2. Korrektheit: Die Software soll die fachliche Regel sicher einhalten.

3. Reflexion: Das Team verbessert regelmäßig seine Arbeitsweise.

4. Produktionseffizienz: Automatisierung spart wiederholte Handarbeit.

Je richtiger Zuordnung 1 Punkt.

Entwurf B ist loser gekoppelt.

• In Entwurf A kennt Kasse den inneren Aufbau der Bestellung: Sie liest die öffentliche Liste positionen und weiß, dass Preis und Menge an Index 1 und 2 eines Arrays bzw. an Position 2 und 3 eines Tupels stehen. Ändert sich die Datenstruktur, muss Kasse mitgeändert werden. In Entwurf B sind die Positionen privat; nur Bestellung selbst kennt sie.

• In Entwurf A liest Kasse den Gutscheincode als Zeichenkette aus der Bestellung und vergleicht ihn selbst mit "KURIER10". In Entwurf B hängt Bestellung nur von der Operation rabattCent(...) bzw. rabatt_cent(...) des Gutscheins ab und übergibt dabei einen einzelnen Wert (Datenkopplung).

Bewertung: Entscheidung mit Begründung 1 Punkt, je stichhaltige Stelle 1,5 Punkte.

Kasse hat eine geringe Kohäsion: Sie berechnet Rabatte, formatiert Geldbeträge und baut Newsletter-Texte. Die drei Methoden nutzen keine gemeinsamen Daten und hätten verschiedene Gründe, sich zu ändern (Rabattregeln, Darstellung von Beträgen, Marketing). Das ist zufällige Kohäsion, ein typisches Merkmal von Sammelklassen.

Gutschein hat eine hohe Kohäsion: Die Klasse hat genau eine Aufgabe (den Rabatt eines Gutscheins berechnen), und ihre Methode arbeitet mit ihrem eigenen Attribut prozent.

Bewertung: je Klasse 1 Punkt für die Einstufung und 1 Punkt für die Begründung.

• Entwurf A: Für den neuen Code muss die Methode rabattCent bzw. rabatt_cent der Kasse um eine weitere Abfrage mit neuer magischer Zahl erweitert werden. Für die Bezeichnung ändert sich das Array bzw. Tupel der Positionen; alle Stellen, die mit Indizes bzw. Entpacken darauf zugreifen (hier die Kasse, im ganzen Shop vermutlich weitere), müssen angepasst werden.

• Entwurf B: Der neue Gutschein ist nur ein weiteres Objekt Gutschein("FRUEHLING5", 5); die Rabattberechnung bleibt unverändert (die Zuordnung Code → Gutschein liegt an einer Stelle außerhalb der gezeigten Klassen). Die Bezeichnung wird als neues Feld im record bzw. in der dataclass Position ergänzt; Bestellung und Gutschein bleiben unberührt, nur die Stellen, die Positionen erzeugen, bekommen den neuen Wert.

• Der Vergleich betrifft den Wert Wandelbarkeit: Entwurf B lässt sich mit weniger und besser eingegrenzten Änderungen anpassen.

Bewertung: je Entwurf 1,5 Punkte, Wert 1 Punkt.

Je sinnvollem Prüfpunkt mit passender Begründung 1 Punkt, höchstens 6 Punkte; fehlt der Bezug zu Entwurf A, höchstens 5 Punkte.

• Der Test prüft nur das Ergebnis 1034 Cent für eine Bestellung. Er sagt nichts darüber, dass Kasse über die öffentliche Liste und feste Indizes bzw. das Entpacken eines Tupels in die Bestellung greift. Die enge Kopplung fällt erst auf, wenn sich die Positionen ändern, und dann scheitern viele Stellen gleichzeitig.

• Die Methode newsletterText bzw. newsletter_text hat mit dem Rabatt nichts zu tun. Kein Test bemerkt, dass die Klasse dadurch zur Sammelklasse mit geringer Kohäsion wird; ebenso wenig die magische Zahl und der fest eingetragene Code "KURIER10".

• Weitere mögliche Punkte: Randfälle wie eine leere Bestellung oder ein unbekannter Code sind nicht getestet; der Code formatiert Geldbeträge vielleicht doppelt zu einer vorhandenen Methode.

• Absichern mit wenig Aufwand: Jeden Vorschlag kurz nach der Checkliste aus d) durchsehen (bei wenigen Zeilen in Minuten erledigt), für neue Regeln eigene Tests ergänzen, den Vorschlag als eigenen Commit übernehmen und die statische Codeanalyse in der CI mitlaufen lassen.

Bewertung: je erläuterter Stelle 1 Punkt, Vorgehen zum Absichern 2 Punkte.