EPROG Tutorium #4 Philipp Effenberger

1. EPROG Tutorium #4Philipp Effenberger Objektorientierte Programmierung Beziehungen Abstraktion Kapselung Wiederverwendung & Wartbarkeit Javadoc philipp_effenberger@web.de

2. Wiederholung Tutorium #3 • switch-Statement • Static member variable – member variable • Methoden – Aufbau • Methodenheader: Integer x, Kontrolle x>0? • Methodenheader: Objekt Computer mit int ID, ArrayList<String> Bestandteile, String Besitzer Wie viele Teile hat der Computer? • Konstruktor • Neues Objekt? • Neues Objekt mit String Bezeichner? • Neues Objekt mit int Nummer, String Name, double Wert? • Neues Objekt mit ArrayList<Object>? philipp_effenberger@web.de

3. Beziehung • Klassen und dementsprechend Objekte stehen normalerweise in einer Beziehung zueinander. • Generalisierung “is_a“ Beziehung • Fahrrad is_a Zweirad is_a Transportmittel… • Aggregation “part_of“ Beziehungen • Schlauch part_of Reifen part_of Fahrrad… • Verwendungs- und Aufrufbeziehung • Ich *arbeite_mit* Studenten *arbeiten_mit* Computer… philipp_effenberger@web.de

4. Abstraktion • Trennung Konzept – Umsetzung: • z.B.: ich will einen grauen Stetsonhut aufsetzen • Ich bin ein Besitzer mit verschiedenen Eigenschaften • Stetsonhut ist ein Hut mit verschiedenen Eigenschaften • Konzept auch für alle andere Menschen/Hüte anwendbar • Hut hat Eigenschaft z.B.: • Besitzer • Typ • Farbe • Grösse • Besitzer hat Eigenschaft: • Kopfgrösse • Alter • … philipp_effenberger@web.de

5. Abstraktion 2 • Wichtig ist zu wissen, • wie bediene ich das Objekt, • welche Eigenschaften hat das Objekt und wie verhält es sich, • wie erzeuge ich das Objekt. • Die Klasse ist quasi das abstrakte Objekt, das dann seine Eigenschaften bekommt (dieser Hut ist pink, dieser Hut blau,…; alle Hüte haben aber eine (eigene) Farbe) philipp_effenberger@web.de

6. Kapselung • member variables • Sollten immer private sein; so kann man unvorhergesehene Zugriffe/ungewollte Veränderungen ausschließen. • Veränderbar über Methoden, in allen Objekten einer Klasse vorhanden, können aber unterschiedlichen Inhalt haben und sich in der Runtime verändern. • Objektverhalten (=vorhandene Methoden) • Schnittstelle mit dem Objekt, hier kann man alles vom Objekt erfahren, mit dem Objekt arbeiten. • Kontrolliertes Verhalten; ist ja schließlich selbst programmiert, also (in den meisten ;-) ) Fällen vorhersehbar. philipp_effenberger@web.de

7. Wiederverwenbarkeit, Wartbarkeit • Vererbung ermöglicht Benützung von Code aus anderen Klassen • Ermöglicht so komplexe Konstrukte • Taste wird Keyboard, Keyboard wird I/O für NASA Rakete… • Schnittstelle übersichtlich gestalten (!), denn dann braucht man den Code nicht zu kennen, trotz Benützung • public int getGroesse( Object XYZ ) Ich weiß: öffentlich zugänglich, Objekt XYZ muss übergeben werden, Integer als Ergebnis zurück ans Programm • Code an nur einer Stelle ist leicht zu korrigieren bei Fehlern! philipp_effenberger@web.de

8. Javadoc • Dient zur Dokumentation von Programmen • Wird innerhalb des .java Files als Kommentar dazugeschrieben und kann dann kompiliert werden • Formatierung: /** * @param ch the character to be tested… */ • javadoc [-private] Klassenname.java (auch *.java möglich) • Links: • http://mindprod.com/jgloss/javadoc.html • http://java.sun.com/j2se/javadoc/ philipp_effenberger@web.de

9. Javadoc – kurze Referenz * @param (classes, interfaces, methods and constructors only) * @return (methods only) * @exception (@throws is a synonym added in Javadoc 1.2) * @author (classes and interfaces only, required) * @version (classes and interfaces only, required. See footnote 1) * @see * @since * @serial (or @serialField or @serialData) * @deprecated (see How and When To Deprecate APIs) philipp_effenberger@web.de