10. Gutes Programmieren Grundlagen der Programmierung 1 (Java)

10. Gutes Programmieren
Grundlagen der
Programmierung 1 (Java)
Fachhochschule Darmstadt
Haardtring 100
D-64295 Darmstadt
Prof. Dr. Bernhard Humm
FH Darmstadt, 20. Dezember 2005
Einordnung im Kontext der Vorlesung
1. Einführung
10. Gutes Programmieren
2. Einfache Programme
11. Rekursion
3. Kontrollstrukturen
12. Algorithmen und Datenstrukturen II
4. Objekt-Orientierung I
13. Objektorientierung II
5. Algorithmen und Datenstrukturen I
14. Komponenten
6. Interfaces
15. Design
7. Pakete
16. Die Java Klassenbibliothek I
8. Generics
17. Die Java Klassenbibliothek II
9. Fehler und Ausnahmen
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 2
Agenda
Agenda
Übersicht
Übersicht
Konventionen
Information Hiding
Defensives Programmieren
Goldene Regeln
Literatur
Debugging mit Eclipse
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 3
Übersicht
Merkmale guter Programme
„Ein gutes Programm hat ein sauberes Layout, verwendet
sinnvolle Namen, ist ausführlich kommentiert und verwendet
Konstrukte der Sprache derart, dass maximale Robustheit und
Lesbarkeit des Programms erreicht werden.
Die Erstellung eines solchen Programms erfordert vom
Programmierer Sorgfalt, Disziplin und ein gutes Stück
handwerklichen Stolz.“
Ian Sommerville, „Software Engineering“, Addison-Wesley 1987
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 4
Übersicht
Qualitätskriterien (1/2)
Korrektheit
– das Programm soll die gewünschte Funktionalität liefern
– (fast) alle größeren Programme enthalten noch Fehler (bugs)
– Vorgehen:
– guter Programmierstil
– intensives Testen des Programms
Lesbarkeit
– der Programmcode soll möglichst verständlich sein
– Vorgehen:
– sinnvolle Namen verwenden: zinsSatz statt z
– gutes Layout des Sourcecode: Einrückungen und Leerzeilen
– Kommentare einfügen
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 5
Übersicht
Qualitätskriterien (2/2)
Wiederverwendbarkeit
– nicht Software für die selben Aufgaben immer wieder neu schreiben: z.B.
Adreßverwaltung
– vorhandene Software benutzen: billiger und fehlerfreier
– Vorgehen:
– vorhandene Klassen suchen: vollständig benutzen oder anpassen
– eigene Klassen so schreiben, daß sie wiederverwendet werden können ?
Effizienz
– Programme sollen klein und schnell sein
– Vorgehen:
– nur erforderliche Variablen deklarieren
– die selben Befehle nicht redundant benutzen: Methoden deklarieren
– mehrfach benötigte Ergebnisse nur einmal berechnen und dann abspeichern
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 6
Agenda
Agenda
Übersicht
Konventionen
Konventionen
Information Hiding
Defensives Programmieren
Goldene Regeln
Literatur
Debugging mit Eclipse
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 7
Konventionen
Namenskonventionen
Grundsätzlich sind kurze aber prägnante Namen zu wählen
Paketnamen bestehen nur aus Kleinbuchstaben. Um Eindeutigkeit zu
erreichen ist ein Top-Level Domain Prefix zu verwenden
Klassen- und Schnittstellennamen werden aus Hauptwörtern
zusammengesetzt. Die einzelnen Wörter beginnen jeweils mit
Großbuchstaben
Methodennamen sind Verben und beginnen mit einem
Kleinbuchstaben. Folgende Wörter werden groß geschrieben
Konstantennamen bestehen nur aus Großbuchstaben und
Unterstrichen
Variablennamen beginnen mit einem Kleinbuchstaben, folgende Wörter
groß. Temporäre Variablen vom Typ int i, j, k, l, m, n und
char mit c, d, e.
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 8
Agenda
Agenda
Übersicht
Konventionen
Information Hiding
Information
Hiding
Defensives Programmieren
Goldene Regeln
Literatur
Debugging mit Eclipse
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 9
Information Hiding
Zugriffsschutz in Java
Zugriffsschutz für Attribute und Methoden
– Richtlinien für Attribute
– Deklarieren Sie Attribute möglichst nie als public (Datenkapselung)
– Deklarieren Sie Attribute, die nur innerhalb der
Klassenimplementierung benötigt werden, als private oder default
– Deklarieren Sie Attribute, auf die evtl. jemand zugreifen muss, wenn er
eine Klasse von der Klasse ableitet, immer als protected
– Konstanten werden i.a. als public deklariert (lassen sich sowieso
nicht verändern)
– Richtlinien für Methoden
– Deklarieren Sie nur die Methoden als public, die Sie anderen zur
Verfügung stellen wollen
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 10
Information Hiding
Zugriffsschutz in Java
Klassen eines
anderen Paketes
Unterklasse eines
anderen Paketes
Klasse im
selben Paket
eigene Klasse
private
public
Elemente einer
Klasse
eigene Klasse
default
protected
Klasse im
selben Paket
eigene Klasse
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
eigene Klasse
Unterklasse eines
anderen Paketes
Klasse im
selben Paket
20.12.2005, Seite 11
Information Hiding
Zugriffsschutz in Java
– Über Zugriffsmethoden (Getter) wird sichergestellt, dass auf bestimmte
Datenelemente nur lesender Zugriff erlaubt ist
– Beispiel
– Attribute sec und min sollen nur gelesen werden können
– Setzen ist nur über entsprechende set-Methoden möglich
class Time{
private sec;
private min;
public int getSec(){
return sec;
}
public int getMin(){
return min;
}
public set(int min, int sec){
int sekunden = 60*min + sec; //falls sec >59
sec = sekunden/60;
min = sekunden%60; }
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 12
Information Hiding
Schlanke Schnittstellen
Es sollen nur die Methoden public sein, die auch außerhalb der Klasse benötigt
werden
private-Methoden: werden nur innerhalb der Klasse gebraucht
(z.B. Hilfsmethoden für Berechnungen)
– z.B.:
public class Time{
private int min;
private int sec;
....
private int getSeconds() {
return 60*min + sec;
}
private void setTime(int s) {
min = s/60; sec = s%60;
}}
Vorteile schlanker Schnittstellen
– Klassen sind besser verständlich
– Änderungen an private-Methoden nach außen nicht sichtbar
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 13
Information Hiding
Initialisierung von Objekten
Objekte sollten beim Erzeugen sofort mit gültigen Daten versehen werden
die Defaultwerte der Attribute reichen dazu meist nicht aus
class Person {
int alter;
double gehalt;
Public Person (int alter, double gehalt){
this.alter = alter;
this.gehalt = gehalt;
}
}
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 14
Information Hiding
Prinzip der minimalen Annahme
1. Verwende Schnittstellen, wo sie zur Verfügung stehen
Also z.B. Map statt HashMap
2. Verwende die allgemeinste Schnittstelle, die den erforderlichen Dienst
bereitstellt
Also z.B. nach Möglichkeit Collection statt List, oder
Iterator statt ListIterator
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 15
Agenda
Agenda
Übersicht
Konventionen
Information Hiding
Defensives
Programmieren
Defensives Programmieren
Goldene Regeln
Literatur
Debugging mit Eclipse
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 16
Defensives Programmieren
Möglichkeiten der defensiven Programmierung
Assertions
Exceptions
Tracing / Logging
Testfälle
„Programming by Contract“ – Pre-, Postconditions & Invarianten
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 17
Defensives Programmieren
Assertions (ab JDK1.4)
Mit einer Assertion prüfen wir, ob alle Vorbedingungen erfüllt sind
Eine fehlerhafte Assertion führt zu einem AssertionError
Ein AssertionError beendet das (Test)programm
Beispielcode:
public class aClass {
public void aMethod(Object pObject) {
// Check to make sure that all preconditions are true
// Simple flavor
assert pObject != null;
// Complex flavor
assert mObject != null : “mObject is ”+mObject;
}
}
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 18
Defensives Programmieren
Kompilierung mit Assertions
Ab dem JDK1.4 ist assert ein Schlüsselwort
javac -source 1.3 kompiliert ohne assert
javac -source 1.4 kompiliert mit assert
Standardmäßig wird ohne assert kompiliert
Abwärtskompatibilität wird somit vom Hersteller gewährleistet
Wenn assert eingesetzt wird, kann das Programm in keinem JRE
kleiner 1.4 laufen
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 19
Defensives Programmieren
Exceptions
Ignoriere niemals eine Ausnahme
Befasse dich schon in frühen Phasen mit der Ausnahmebehandlung
Nutze finally zur Schonung von Ressourcen
Benutze keine Ausnahmen zum Programmfluss
Eine Klasse mit einer statusabhängigen Methoden sollte immer eine
statusprüfende Methode bereitstellen
Leite immer von RuntimeException oder von Exception ab,
niemals von Error
Bevorzuge den Einsatz der im Standard enthaltenen Ausnahmen
Dokumentiere jede Exception die von einer Methode geworfen
werden kann
Verfasse eine aussagekräftige Meldung
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 20
Defensives Programmieren
Wann ist ein Rückgabewert besser als eine Exception ?
Wenn es einen natürlichen Weg gibt, den Ausgang der Methode mitzuteilen,
sollte er gewählt werden
Beispiel: „Öffnen einer Datei“
public boolean open(String filename)
throws FileNotFoundException {
File f = new File(name);
if (!f.exists()) {
return false;
}
mInputStream = new FileInputStream(f);
return true;
Aus dem Pragmatischen Programmierer
}
– Der boolean-Wert gibt an, ob die Datei existiert oder nicht
– Die Ausnahme wird geworfen, wenn das Dateisystem defekt ist
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 21
Defensives Programmieren
Logging (ab JDK1.4)
Einfache Nutzung über ein globales Logger Objekt
Logger.global.info(„log me“);
Die angemessene Nutzung der Logging Funktionalität
Logger logger = Logger.getLogger(„current.package“);
logger.info(„log me“);
Das Format einer Log-Meldung
Dec 19, 2001 2:41:13 PM MyProgram main
INFO: log me
Kann ohne zu kompilieren an- und abgeschalten werden
Ein Neustart ist allerdings nicht vermeidbar
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 22
Defensives Programmieren
Logging Stufen
SEVERE – Desaströse Fehler, die einer sofortigen Behandlung
bedürfen. Der Betrieb kann nicht mehr vollständig gewährleistet
werden.
WARNING – Schwerwiegende Probleme, die einer gesonderten
Ausnahmebehandlung bedürfen.
INFO – Der Default-Level, in dem alle fachlichen Protokollierungen
vorgenommen werden
CONFIG – Protokolliert die Konfigurationseinstellungen
FINE, FINER, FINEST – Detailierte Log-Informationen zum
debuggen eines Programms.
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 23
Agenda
Agenda
Übersicht
Konventionen
Information Hiding
Defensives Programmieren
Goldene
Regeln
Goldene Regeln
Literatur
Debugging mit Eclipse
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 24
Goldene Regeln
Goldene Regeln der Programmierung
Methoden mit mehr als 30 Zeilen haben Fehler. Ziel: 99% aller
Methoden sind kürzer; die wenigen Komplexitätsnester testen bis zum
Letzten.
Komplexität in die Datenstruktur, nicht in den Ablauf. Die Wahl des
richtigen Behälters (z.B. Set anstelle von Array) spart eine Seite Code.
Denken in einfachen mathematischen Begriffen
– Funktionen und Prädikate, Intervalle, Mengen, Operationen darauf
(Vereinigung, Durchschnitt, Differenz)
Schreibe Code nur einmal – Refactoring von wiederkehrender
Funktionalität
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 25
Goldene Regeln
Goldene Regeln während der Arbeit
Inkrementell arbeiten: Schnittstelle, Implementierung und Testtreiber
entstehen gleichzeitig. Niemals ohne Testtreiber.
Umgebung sauber definieren: Welche Pfade brauche ich, wo ist
meine Baustelle, was verwende ich nur ohne es zu ändern.
Den Debugger und Logging verwenden
Fehler isolieren: Einen Testtreiber auf genau die problematischen
Aufrufe reduzieren.
Pause machen oder ins Bett gehen, wenn man nicht mehr durchblickt
☺
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 26
Agenda
Agenda
Übersicht
Konventionen
Information Hiding
Defensives Programmieren
Goldene Regeln
Literatur
Literatur
Debugging mit Eclipse
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 27
Literatur
Literatur
Effective Java. Programming Language Guide. Joshua Bloch, Addison
Wesley Professional, 2001, ISBN 0201310058
http://developer.java.sun.com/developer/Books/effectivejava/Chapter3.
pdf
Vermeulen, et al; Elements of Java Style; SIGS, 2000
Ambler; Writing Robust Java Code;
http://www.AmbySoft.com/javaCodingStandards.pdf
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 28
Agenda
Agenda
Übersicht
Konventionen
Information Hiding
Defensives Programmieren
Goldene Regeln
Literatur
Debugging
mitEclipse
Eclipse
Debugging mit
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 29
Debugging mit Eclipse
Bernhard Humm: „Grundlagen der Programmierung I (Java)“. FH Darmstadt, WS 2005/2006
20.12.2005, Seite 30