Objektorientierte Programmiertechniken
LVA 185.A01, VU, 3 ECTS, 2014/2015 W

5. Übungsaufgabe

Themen:

Generizität, Container und Iteratoren

Termine:

Ausgabe: 12.11.2014
Abgabe: 19.11.2014, 12:00 Uhr

Abgabeverzeichnis:

Aufgabe5

Programmaufruf:

java Test

Grundlage:

Skriptum, Schwerpunkt auf den Abschnitten 3.1 und 3.2

Aufgabe

Welche Aufgabe zu lösen ist:

Entwickeln Sie in Java Klassen bzw. Interfaces entsprechend folgender Beschreibung:

Ein Aufruf von java Test soll wie gewohnt Testfälle ausführen und die Ergebnisse in allgemein verständlicher Form darstellen. Anders als in bisherigen Aufgaben sind die Überprüfungen jedoch vorgegeben und in dieser Reihenfolge auszuführen:

  1. Erzeugen Sie je eine Datenstruktur der Typen Wood<String>, SortedWood<Skier> und SortedWood<Snowboarder> mit mehreren Ebenen, fügen Sie jeweils einige Elemente ein, und geben Sie alle Elemente (bei Personen inklusive Köpergewicht bzw. Körpergröße) so aus, dass die Struktur sichtbar wird. Geben Sie die Elemente von SortedWood<Skier> in entsprechend prec aufsteigend sortierter Reihenfolge aus, jene von SortedWood<Snowboarder> in absteigend sortierter Reihenfolge. Suchen Sie über contains nach jeweils einigen Elementen und geben Sie die Teilbäume unterhalb der gefundenen Elemente aus. Entfernen Sie Elemente, fügen Sie Elemente ein und geben Sie die Inhalte der Datenstrukturen erneut aus.
  2. Erzeugen Sie eine Datenstruktur vom Typ SortedWood<Person>. Lesen Sie über Iteratoren alle Elemente aus den in Punkt 1 erzeugten Datenstrukturen der Typen SortedWood<Skier> und SortedWood<Snowboarder> aus und fügen Sie diese in die neue Datenstruktur ein. Überprüfen Sie die Funktionalität der Datenstruktur wie in Punkt 1, allerdings ohne Köpergewichte bzw. Körpergrößen auszugeben.
  3. Erzeugen Sie weitere Datenstrukturen vom Typ SortedWood<Person> und fügen Sie diese in eine Datenstruktur vom Typ SortedWood<SortedWood<Person>> ein. Testen Sie die Funktionalität wie in Punkt 1, wobei Sie jedoch statt der Köpergewichte bzw. Körpergrößen die Inhalte der enthaltenen Elemente vom Typ SortedWood<Person> ausgeben.
  4. Betrachten Sie die in Punkt 2 erzeugte Datenstruktur so, als ob sie vom Typ Wood<Person> wäre (z.B., indem Sie die Datenstruktur an eine Variable vom deklarierten Typ Wood<Person> zuweisen und die folgenden Tests auf dieser Variablen ausführen). Testen Sie die Funktionalität wie in Punkt 1, allerdings ohne Köpergewichte bzw. Körpergrößen auszugeben und die zusätzliche Funktionalität von SortedWood zu verwenden.
  5. Machen Sie optional weitere Überprüfungen, die Ihnen notwendig und sinnvoll erscheinen.

Daneben soll die Klasse Test.java als Kommentar eine kurze, aber verständliche Beschreibung der Aufteilung der Arbeiten auf die einzelnen Gruppenmitglieder enthalten – wer hat was gemacht.

Wie die Aufgabe zu lösen ist:

Von allen oben beschriebenen Interfaces, Klassen und Methoden wird erwartet, dass sie überall verwendbar sind. Der Bereich, in dem weitere eventuell benötigte Klassen, Methoden, Variablen, etc. sichtbar sind, soll jedoch so klein wie möglich gehalten werden.

Alle Teile dieser Aufgabe sind ohne Verwendung von Arrays, ohne vorgefertigte Container-Klassen (wie LinkedList, HashSet, etc.) und ohne vorgefertigte Iterator-Implementierungen zu lösen. Benötigte Container und Iteratoren sind selbst zu schreiben.

Typsicherheit soll so weit wie möglich vom Compiler garantiert werden. Auf die Verwendung von Typumwandlungen (Casts) und ähnliche Techniken ist zu verzichten, und der Compiler darf keine Hinweise auf mögliche Probleme im Zusammenhang mit Generizität geben. Achtung: Übersetzen Sie die Klassen mittels javac -Xlint:unchecked *.java; dieses Compiler-Flag schaltet genaue Compiler-Meldungen im Zusammenhang mit Generizität ein. Andernfalls bekommen Sie auch bei schweren Fehlern vom Compiler nur eine harmlos aussehende Meldung (Note: ...). Überprüfungen durch den Compiler dürfen nicht ausgeschaltet werden, auch nicht für Warnungen.

Warum die Aufgabe diese Form hat:

Die Aufgabe ist so konstruiert, dass dabei Schwierigkeiten auftauchen, für die wir Lösungsmöglichkeiten kennengelernt haben.

Durch die Typhierarchie auf Person, Skier und Snowboarder muss Generizität über mehrere Ebenen hinweg betrachtet werden, da vereinfachende Sichtweisen durch die von dieser Hierarchie unabhängigen Typen SortedWood<SortedWood<Person>> und Wood<String> ausgeschlossen sind.

Vorgegebene Testfälle stellen sicher, dass die Schwierigkeiten erkannt werden. Um Umgehungen zu vermeiden sind Typumwandlungen ebenso verboten wie das Ausschalten von Compilerhinweisen auf unsichere Verwendungen von Generizität. Neben Techniken zur Lösung der speziellen Schwierigkeiten wird in dieser Aufgabe auch der Umgang mit Sichtbarkeit und Untertypbeziehungen auf generischen Typen geübt. Am Beispiel von Iteratoren soll intuitiv klar werden, welchen Einfluss die Verwendung innerer Klassen auf die Sichtbarkeit von Implementierungsdetails nach außen hat.

Was im Hinblick auf die Beurteilung wichtig ist:

Die insgesamt 100 für diese Aufgabe erreichbaren Punkte sind folgendermaßen auf die zu erreichenden Ziele aufgeteilt:

Generizität zusammen mit geforderten Untertypbeziehungen richtig verwendet, sodass die Tests (ohne Tricks beim Testen) durchführbar sind 35 Punkte
Zusicherungen richtig und sinnvoll eingesetzt 15 Punkte
Sichtbarkeit auf so kleine Bereiche wie möglich beschränkt 15 Punkte
Lösung wie vorgeschrieben und sinnvoll getestet 20 Punkte
Geforderte Funktionalität vorhanden (so wie in Aufgabenstellung beschrieben) 15 Punkte

Am wichtigsten ist die sinnvolle und korrekte Verwendung von Generizität. Es gibt bedeutende Punkteabzüge, wenn der Compiler mögliche Probleme im Zusammenhang mit Generizität meldet oder wichtige Teilaufgaben nicht gelöst oder umgangen werden.

Ein zusätzlicher Schwerpunkt liegt auf dem gezielten Einsatz von Sichtbarkeit. Es gibt Punkteabzüge, wenn Programmteile, die überall sichtbar sein sollen, nicht public sind, oder Teile, die nicht für die allgemeine Verwendung bestimmt sind, unnötig weit sichtbar sind. Durch die Verwendung innerer Klassen kann das Sichtbarmachen mancher Programmteile nach außen verhindert werden.

Nach wie vor spielen auch Untertypbeziehungen und Zusicherungen eine große Rolle bei der Beurteilung.

Generell führen Abänderungen der Aufgabenstellung – beispielsweise die Verwendung von Typumwandlungen, Arrays oder vorgefertigten Containern und Iteratoren oder das Ausschalten von Überprüfungen durch @SuppressWarning – zu bedeutenden Punkteabzügen.

Complang
Puntigam
   Kontakt
   Research
   Lehre
      OOP
      Typsysteme
      EP2
      FOOP
      Prog.spr.
      frühere Lehre
         LVAs 2017 W
         LVAs 2017 S
         LVAs 2016 W
         LVAs 2016 S
         LVAs 2015 W
         LVAs 2015 S
         LVAs 2014 W
            GPK
            OOP
               1. Aufgabe
               2. Aufgabe
               3. Aufgabe
               4. Aufgabe
               5. Aufgabe
               6. Aufgabe
               7. Aufgabe
               8. Aufgabe
               9. Aufgabe
            Typsysteme
         LVAs 2014 S
         LVAs 2013 W
         LVAs 2013 S
         LVAs 2012 W
         LVAs 2012 S
         LVAs 2011 W
         LVAs 2011 S
         LVAs 2010 W
         LVAs 2010 S
         LVAs 2009 W
         LVAs 2009 S
         LVAs 2008 W
         LVAs 2008 S
         LVAs 2007 W
         LVAs 2007 S
         LVAs 2006 W
         LVAs 2006 S
         LVAs 2005 W
         LVAs 2005 S
         LVAs 2004 W
         LVAs 2004 S
         LVAs 2003 W
   Links
Sitemap
Kontakt
Schnellzugriff:
Tutoren
Lehrunterlagen
vorige Aufgabe
nächste Aufgabe
Fakultät für Informatik
Technische Universität Wien
Anfang | HTML 4.01 | Datenschutzerklärung | letzte Änderung: 2014-11-12 (Puntigam)