Martin Häcker/Java Kurs/Tag 3

<- Zurück zur Übersicht

LE 5: Strukturiertes Programmieren

Vortragende: Arthur, Kristian, Robert Lubkoll

• Wiederholung von Tag 2
  • Da wirds viele studenten geben, die merkwürdige Vorstellungen von Objekten haben
  • Die wollen wir verarzten
• Daran dann die Methodik erklären

Objektorientierung

• public / private

Methodik

• Allgemein: Wie entwickelt man Programme Stück für Stück?
• In der main-Funktion sachen aufrufen -> Da gehts dann bei Testen, weiter
  • Wie zerlegt man ein Problem in kleine Stücke
    • Top-Down vs. Bottom-Up <- letzteres empfiehlt sich für beginnende programmierer
  • Wie zeigt man das das kleine Stück das man schon hat funktioniert

• Konkretes Vorgehen
  • Laufend kompilieren, nicht erst am Ende!
  • Laufend testen, nicht erst am Ende!
  • Wie man das macht

Praxis: Wie verwendet man das

• Beispiel Fehlerbehandlung mit Rückgabewert (C?) (Apple hatte da ein Beispiel Living in an Exceptional World Interessant, aber irrelevant
• Beispiel Fehlerbehandlung mit Exceptions
• Vorsicht: Raymond Chen sagt dazu gerne cleaner, more elegant - and wrong!, Cleaner, more elegant and harder to recognize
• Exceptions sollen NICHT für flow controll verwendet werden

Übungsaufgaben

• Übung: kleines Spiel: "Vier Gewinnt"
  • In der Vorlesung schon anfangen wie man das designt

• Selber ein schlechtes Programm "fehlerbeseitigen lassen"
• schlechte Bezeichnungen durch bessere ersetzen lassen
• Debuggen mit Eclipse
• Fehler die hier eingetreten sind

Vier gewinnt

• vier gewinnt
• highscores
• andere scores
• = vorgabe GUI
• = vorgabe evtl. billige KI die man evtl. im netz findet?

LE 6: Effizient Fehler finden und Testen

Vortragende: Karsten Bsufka, Olaf-Kroll Peters

• Java: Wie findet man effizient Fehler?
  • Greenspuns third law of programming: "Debugging is at least twice as hard as Programming. So, if you program as clever as you can, you are by definition too dumb do debug it."
    • Einfachheit bringt funktionierende Programme
    • Man hat eigentlich ein Kommunikationsproblem: Das was man will, muss man in Code hinschreiben - aber so exact das es sogar ein Computer ausführen kann. Gleichzeitig ist das eigentliche Ziel des Programms, das der Programmierer es lesen und verstehen kann. Für ihn (und andere) ist der code geschrieben!
    • Vorsicht vor
      • langen Funktionen
      • Namen die nicht den zweck einer Variablen zeigen
      • tiefen verschachtelungen
      • komplizierten if-/while-/for-Bedingungen
      • allem was man nicht auf den ersten Blick sieht
    • Beispiele für jede dieser Sachen (if-gotcha, lange funktion, blöde namen, komplizierte if-bedingung (klammerfehler), ...)
  • Hat viel mit erfahrung zu tun - man muss also schon jede menge Fehler finden um gut zu werden - aber es gibt auch techniken
  • Gefundene Fehler korrigieren
  • Debugging (mit Vorführung)
  • Testen: Selber Fehler finden (mit Vorführung)
  • Seperat testen (von main aus)

Übungsaufgaben

<- Zurück zur Übersicht