TDA550 Objektorienterad programvaruutveckling IT, forts. kurs Övning vecka 4

Relevanta dokument
TDA550 Objektorienterad programvaruutveckling IT, forts. kurs Övning vecka 3

Övning 5. TDA550 - Objektorienterad programvaruutveckling, fk

1 Comparator & Comparable

TDA550 Objektorienterad programvaruutveckling IT, forts. kurs Övning vecka 2

Lösningsförslag: Övning 5.

Övning vecka 6. public void method2() { //code block C method3(); //code block D }//method2

TDA550 Objektorienterad programvaruutveckling IT, forts. kurs Övning vecka 3

TDDE10 m.fl. Objektorienterad programmering i Java Föreläsning 6 Erik Nilsson, Institutionen för Datavetenskap, LiU

TDDC30. Objektorienterad programmering i Java, datastrukturer och algoritmer. Föreläsning 4 Erik Nilsson, Institutionen för Datavetenskap, LiU

Övning vecka 5. Denna vecka ska vi titta pa samlingar, generics och designmönstren Decorator, Singleton och Iterator.

Övning 4. I denna övning ska vi titta på icke-muterbarhet kontra muterbarhet, samt metoderna equals, hashcode och clone.

Föreläsning 8 - del 2: Objektorienterad programmering - avancerat

TDDE10 m.fl. Objektorienterad programmering i Java Föreläsning 6 Erik Nilsson, Institutionen för Datavetenskap, LiU

Objektorienterad programmering i Java, datastrukturer och algoritmer. Föreläsning 4 Jonas Lindgren, Institutionen för Datavetenskap, LiU

TDA550 Objektorienterad programvaruutveckling IT, forts. kurs Övning vecka 5

Lösningsförslag till omtentamen för TDA540 Objektorienterad Programmering

Övning vecka 4. Denna vecka ska vi titta på icke-muterbarhet kontra muterbarhet, samt metoderna equals, hashcode och clone.

DAT043 - föreläsning 8

Tentamen Programmering fortsättningskurs DIT950

Outline. Objektorienterad Programmering (TDDC77) En frukt har ett namn. Man kan lägga en frukt i en korg... Hashing. Undantag. Ahmed Rezine.

Lösningsförslag. Programmeringsmetodik, KV: Java och OOP. 17 januari 2004

Abstrakt datatyp. -Algoritmer och Datastrukturer- För utveckling av verksamhet, produkter och livskvalitet.

TDA550 Objektorienterad programvaruutveckling IT, forts. kurs Övning vecka 5

Objektorienterad Programmering (TDDC77)

Länkade strukturer, parametriserade typer och undantag

Föreläsning 9. Generiska enheter Inre klasser Anonyma klasser Kloning

Objektorienterad Programkonstruktion. Föreläsning 4 8 nov 2016

Objektorienterad Programmering DAT043. Föreläsning 9 12/2-18 Moa Johansson (delvis baserat på Fredrik Lindblads material)

Examination i. PROGRAMMERINGSTEKNIK F1/TM1 TIN212 (Dugga) Dag: Onsdag Datum: Tid: (OBS 3 tim) Rum: V

Föreläsning 8: Exempel och problemlösning

Objektorienterad Programkonstruktion. Föreläsning 2 2 nov 2016

LÖSNINGSFÖRSLAG Programmeringsteknik För Ing. - Java, 5p

TDA550 Objektorienterad programvaruutveckling IT, forts. kurs Övning vecka 1

Idag. statiska metoder och variabler. private/public/protected. final, abstrakta klasser, gränssnitt, delegering. wrapper classes

Lösningar för tenta 2 DAT043,

public interface Skrivbar { void skriv(); } public class Punkt implements Skrivbar { public double x; public double y;

Konstruktion av klasser med klasser

Subklasser och arv Inledning till grafik (JFrame och JPanel). Något om interface. Objektorienterad programvaruutveckling GU (DIT011) Subklasser

Idag. Exempel, version 2. Exempel, version 3. Ett lite större exempel

Föreläsning 2. Länkad lista och iterator

Interface. Interface. Tobias Wrigstad (baserat på bilder från Tom Smedsaas) 3 december 2010

TDA550 Objektorienterad programvaruutveckling IT, forts. kurs Övning vecka 4

Algoritmer. Två gränssnitt

2I1049 Föreläsning 5. Objektorientering. Objektorientering. Klasserna ordnas i en hierarki som motsvarar deras inbördes ordning

Objektorienterad programmering i Java Undantag Sven-Olof Nyström Uppsala Universitet Skansholm: Kapitel 11

Tentamen LÖSNINGSFÖRSLAG. c) Tilldelningen C x = new D() ger kompileringsfel eftersom klassen D är abstrakt.

Tentamen Programmeringsteknik II Inledning. Anmälningskod:

Föreläsning 4 Innehåll. Abstrakta datatypen lista. Implementering av listor. Abstrakt datatypen lista. Abstrakt datatyp

DAT043 Objektorienterad programmering för D, DIT011 Objektorienterad programvaruutveckling för GU

Objektorienterad programmering i Java Undantag Sven-Olof Nyström Uppsala Universitet Skansholm: Kapitel 11

Föreläsning 3. Stack

Laboration 13, Arrayer och objekt

Vad handlar kursen om? Algoritmer och datastrukturer. Vad handlar kursen om? Vad handlar kursen om?

DAT043 Objektorienterad Programmering

Arv: Fordonsexempel. Arv. Arv: fordonsexempel (forts) Arv: Ett exempel. En klassdefinition class A extends B {... }

Mutability och State. Objekt-orienterad programmering och design (DIT953) Niklas Broberg / Johannes Åman Pohjola, 2018

TENTAMEN OOP

Föreläsning 3. Stack

Detta dokument är ett exempel, cirka hälften av en tentamen för TDA545 Objektorienterad programvaruutveckling

Kompilering och exekvering. Föreläsning 1 Objektorienterad programmering DD1332. En kompilerbar och körbar java-kod. Kompilering och exekvering

Seminarium 3 Introduktion till Java Collections Framework Innehåll. Generik Bakgrund. Exempel på en generisk klass java.util.arraylist.

Lite om felhantering och Exceptions Mer om variabler och parametrar Fält (eng array) och klassen ArrayList.

Kungl. Tekn. Högskolan Förel 1, bild 1 Föreläsning 1: Introduktion ffl Kursinnehåll ffl Javarepetition ffl Referenser ffl Nyckelordet static ffl Klass

UML. Klassdiagr. Abstraktion. Relationer. Överskugg. Överlagr. Aktivitetsdiagram Typomv. Typomv. Klassdiagr. Abstraktion. Relationer.

Föreläsning 3-4 Innehåll

Föreläsning 8. Arv. Arv (forts) Arv och abstrakta klasser

LULEÅ TEKNISKA UNIVERSITET

F12 - Collections. ID1004 Objektorienterad programmering Fredrik Kilander

TENTAMEN PROGRAMMERINGSMETODIK MOMENT 2 - JAVA, 4P

Klasshierarkier. Klasser kan byggas på redan definierade klasser

Tentamen ID1004 Objektorienterad programmering May 29, 2012

Lösningsförslag till tentamen FYTA11 Javaprogrammering

Objektsamlingar i Java

Programmering med Java. Grunderna. Programspråket Java. Programmering med Java. Källkodsexempel. Java API-exempel In- och utmatning.

Tentamen ID1004 Objektorienterad programmering October 29, 2013

Lösningsförslag till tentamen

Föreläsning 3-4 Innehåll. Diskutera. Metod. Programexempel med metod

Klasshierarkier - repetition

TDDC30. Objektorienterad programmering i Java, datastrukturer och algoritmer. Föreläsning 1 Jonas Lindgren, Institutionen för Datavetenskap, LiU

Föreläsning 9: Arv och UML

Objektorienterad programutveckling, fk

Lösningsförslag till exempeltenta 2

Föreläsning 2. Länkad lista och iterator

Föreläsning 2, vecka 8: Repetition

TDDE10 TDDE11, 725G90. Objektorienterad programmering i Java, Föreläsning 3 Erik Nilsson, Institutionen för Datavetenskap, LiU

Grundkurs i programmering, 6 hp (725G61) Dugga 2 tillfälle 2

TDDC30. Objektorienterad programmering i Java, datastrukturer och algoritmer. Föreläsning 2 Jonas Lindgren, Institutionen för Datavetenskap, LiU

DAT043 - Föreläsning 7

E02 "The Review" Föreläsning 2, HT2013 Grunderna, repetition. Johan Leitet. Kurs: 1dv403 Webbteknik I

Tentamen Objekt-orienterad programmering i Java, 5p distanskurs

Det är principer och idéer som är viktiga. Skriv så att du övertygar rättaren om att du har förstått dessa även om detaljer kan vara felaktiga.

PROGRAMMERINGSTEKNIK TIN212

TDDC30. Objektorienterad programmering i Java, datastrukturer och algoritmer. Föreläsning 2 Erik Nilsson, Institutionen för Datavetenskap, LiU

Seminarium 2 Introduktion till Java Collections Framework Innehåll. Generik Bakgrund. Exempel på en generisk klass java.util.arraylist.

Överlagring, static, testning, formella metoder och undantag! Förelasning 13!! TDA540 Objektorienterad Programmering!

Föreläsning 12: Exempel och problemlösning

Att deklarera och att använda variabler. Föreläsning 10. Synlighetsregler (2) Synlighetsregler (1)

Språkkonventioner och redigering av tal.

Ett problem. Kontrollstrukturer och arrayer. Arrayer. Lösningen. Arrayer och hakparanteser. Exempel int[] results; results = new int[10]; // 0..

Subtyping, co- och contra-variance. Objekt-orienterad programmering och design Alex Gerdes, 2016

Transkript:

TDA550 Objektorienterad programvaruutveckling IT, forts. kurs Övning vecka 4 Pelle Evensen 16 oktober 2012 Sammanfattning Denna vecka ska vi titta på gränssnitten Comparable och Comparator samt exceptions, strategy-designmönstret samt icke-muterbarhet kontra muterbarhet. Vi gör också små återbesök på temat programming by contract. Övningarna är graderade (något subjektivt) från lätt ( ) till svår ( ). Svårighetsgraden hos en övning har inte nödvändigtvis med lösningens storlek att göra. 1 Comparator & Comparable Vi kan för en viss klass göra så att den får en total ordning genom att låta den implementera gränssnittet Comparable. I de fall då vi vill tillhandahålla mer än en ordning för en klass använder vi oss av gränssnittet Comparator. Detta kan vi så klart också använda för att ordna objekt av en klass som inte redan implementerar Comparable. Exceptionsövningar ursprungligen lånade av Bror Bjerner 1

1.1 Implementation av Comparable I fig. 1 ges klassen Car. Vi vill göra så att klassen vid sortering sorteras i stigande ordning jämförandes följande variabler; 1. modelyear 2. manufacturer 3. modelname Om två bilar är av samma årsmodell så jämför man också tillverkare, om tillverkare också är lika, jämför också modellnamn. Skriv om compareto i Car så att den får denna totala ordning. public final class Car implements Comparable<Car> { private final String manufacturer; private final String modelname; private final int modelyear; private final String serialnumber; // Accessors go here. public String tostring() { return getclass().tostring() + " manufacturer: " + this.manufacturer+ " modelname: " + this.modelname + " modelyear: " + this.modelyear + " serialnumber: " + this.serialnumber; public Car(String manufacturer, String modelname, int modelyear, String serialnumber) { this.manufacturer = manufacturer; this.modelname = modelname; this.modelyear = modelyear; this.serialnumber = serialnumber; public int compareto(car c) { // Your code here. throw new UnsupportedOperationException("compareTo missing! Help!"); public boolean equals(object o) { // Your code here. throw new UnsupportedOperationException("equals missing! Help!"); Figur 1: Klassen Car. 2

1.2 Rimliga förvillkor för en mer flexibel Comparator Det kan tänkas att man inte kan förutspå alla totala ordningar som kan vara av intresse vid en senare tidpunkt. Ett vanligt fall är då vi i en applikation visar en tabell och man genom att klicka på kolumnernas rubriker bestämmer om posterna ska sorteras i stigande eller fallande ordning med avseende på värdet i kolumnen. Givet att vi har n kolumner så kan dessa sorteras (med ett av alternative stigande eller fallande) på n! olika sätt. Om vi dessutom lägger till egenskapen att vi ska kunna ha både stigande och fallande ordning för varje fält individuellt så får vi 2 n n! möjliga ordningar. Även för små n blir detta snabbt ohanterligt. Vi skulle t.ex. behöva 384 olika komparatorer för att få alla totala ordningar av 4 fält (2 4 4! = 16 24 = 384). public enum Field { MANUFACTURER, MODELNAME, MODELYEAR, SERIAL public enum Order { ASCENDING, DESCENDING Figur 2: Enum-typerna Field och Order. * A comparator that can provide all total orderings for a Car-object. * @inv Describe reasonable class invariants. class CarComparator implements Comparator<Car> { private final Field[ ] f; private final Order[ ] o; * @pre Describe reasonable preconditions. public CarComparator(Field[ ] f, Order[ ] o) { // Your implementation. public int compare(car c1, Car c2) { // Your implementation. throw new UnsupportedOperationException("compare missing! Help!"); Figur 3: Klassen CarComparator. 3

1.2.1 Förvillkor och kontrakt? Klassen CarComparator (fig. 3) är ett skelett för att kunna tillhandahålla alla möjliga komparatorer för att ordna objekt av typ Car. Vilka förvillkor (preconditions) för konstruktorn är rimliga? Har t.ex. alla par av fält och ordning en vettig tolkning? Ger alla unika val av t.ex. par och tripplar distinkta totala ordningar? Tips: Jämför storleken på definitionsmängden för konstruktorn med antalet totala ordningar för 2 fält. Definitionsmängdens storlek är antalet element i den cartesiska produkten, alltså antalet möjliga distinkta tupler för parameter 1 gånger antalet möjliga indata för parameter 2, et.c. Om vi t.ex. har en metod method(int a, int b) så är definitionsmängdens storlek 2 32 2 32 = 2 64 en int i Java har ju 32 bitar. Två int efter varandra blir då 64 bitar som tillsammans kan anta 2 64 olika värden. Den cartesiska produkten för ett jämförelsekriterium är alltså i detta fall antalet datafält (tillverkare, modellnamn, årsmodell och serienummer) gånger antalet ordningar för dessa fält (stigande, fallande). Om vi kallar storleken på denna mängd p så blir definitionsmängdens storlek för n jämförelsekriteria p n. Det bör gå att ställa upp åtminstone sju separata förvillkor för f och o tillsammans. För att skapa en någorlunda flexibel, om än kanske inte så snabb, lösning på det allmäna fallet passar decorator-designmönstret utmärkt. Om detta ännu inte gåtts igenom på kursen kan man senare återkomma hit och fundera på hur en sådan lösning kan se ut. 2 Strategi-designmönstret Strategier är en lämplig taktik att ta till då bara delar av en implementation varierar. Gränssnittet Comparator är ett exempel inom Javas standard-api som är en ren strategi. I en typisk sorteringsalgoritm är det lämpligt att bryta ut själva jämförelsen av elementen från resten av algoritmen. Som vi sett i problemet med CarComparator ovan så kan jämförelsekriterierna också förändras under körning. 1. 2.1 Numerisk integrering Metoden integrate i klassen Integrator (fig. 4, sid. 5) gör en numerisk skattning av integralen b a f k(x) dx där f k (x) är någon av funktionerna f 1 (x) = log(log(x)), f 2 (x) = x x, f 3 (x) = sin(sin(x)). Ett allvarligt problem med denna klass är att vi måste förändra den varje gång vi numeriskt vill integrera en ny funktion, trots att metoden för själva integrationen inte förändras. Vi kan därmed inte skapa nya funktioner under körning. Skriv om klassen Integrator så att den istället för fasta funktioner tar en strategi som parameter till metoden integrate. Du behöver bara skapa ett korrekt 1 Se gärna Item 21 i [Blo08] 4

gränssnitt (interface) samt förändra metoden integrate på lämpligt vis. Tips: Enum-typen Function ska inte finnas med. public class Integrator { public enum Function { FUNCTION1, FUNCTION2, FUNCTION3 ; public static double integrate(function f, double a, double b, int steps) { double sum = 0.0; double previous = fun(f, a); double delta = (b a) / steps; for (int i = 1; i <= steps; i++) { double x = a + (b a) * i / steps; double current = fun(f, x); // Compute the integral through Simpson s 3/8 rule. sum += delta / 8 * (previous + current + 3 * (fun(f, (2 * (x delta) + x) / 3.0) + fun(f, (3 * x delta) / 3.0))); previous = current; return sum; private static double fun(function f, double x) { switch (f) { case FUNCTION1: { return Math.log(Math.log(x)); case FUNCTION2: { return Math.pow(x, x); case FUNCTION3: { return Math.sin(Math.sin(x)); default: throw new IllegalArgumentException("Illegal function!"); Figur 4: Klassen Integrator. 3 Exceptions 3.1 Propagering av fel uppför anropsstacken En fördel med exceptions är möjligheten att propagera felrapportering uppåt i anropsstacken. Betrakta PseudoKod1 (sid. 6). Antag att metoden readfile() är den fjärde metoden som anropas i en serie av nästlade anrop från vår mainmetod: metod1() anropar metod2(), som anropar metod3(), vilken slutligen anropar readfile(). Antag vidare att metod1() i PseudoKod1 är den enda metod som är intressant för hantering av något fel som uppstått i readfile(). 5

3.1.1 Om vi inte haft exceptions? Gör en implementation i pseudo-kod av dessa metoder utan att använda exceptions, d.v.s. komplettera PseudoKod2 (sid. 6) med metoderna metod2 och metod3. Antag att readfile() rapporterar ett fel på samma sätt som metod2() gör i PseudoKod2. 3.1.2 Exceptions räddar dagen? Hur kan nu koden i PseudoKod2 skrivas om med användning av exceptions? Antag att vi kan använda oss av en exception-typ ReadFileFailedException. 3.2 Arv av exceptions Antag att du i Java har definierat en egen klass NotANumberException som en subklass till Exception. Vidare har du definierat ytterligare en klass NotAPositiveNumberException som en subklass till NotANumberException. void metod1() { do something A; metod2(); do something B; void metod2() { do something C; metod3(); do something D; void metod3() { do something E; readfile(); do something F; do something A; error = metod2(); if (error) doerrorprocessing; else do something B;...... Figur 6: Klassen PseudoKod2. Figur 5: Klassen PseudoKod1. 3.2.1 Vad fångas I? Kommer koden i Catcher1 att fånga ett NotAPositiveNumberException? Varför/Varför inte? 3.2.2 Vad fångas II? Kommer koden i Catcher2 att fungera? Varför/Varför inte? 6

catch(notanumberexception nane) { System.out.println("Fångade ett " + "NotANumberException"); Figur 7: Klassen Catcher1. try {... catch(notanumberexception nane) { System.out.println("Fångade " + "ett NotANumberException"); catch(notapositivenumberexception napne) { System.out.println("Fångade ett " + "NotAPositiveNumberException"); Figur 8: Klassen Catcher2. 4 (Icke-)muterbarhet Betrakta klassen Pair (fig. 9, sid. 8). Avsikten med denna klass är att den ska kunna fungera då man behöver en ad-hoc sammansättning av data där det inte finns någon tydlig operation på just denna kombination av data. Denna klass tillåter sammansättning av just par. Då Java inte har något inbyggt stöd för tupler 2 kan detta (för specialfall, t.ex. par, triplar, et.c.) simuleras på detta vis. Vi har inte pratat om generics på kursen ännu. Om du inte har en klar bild av vad <A, B> i klassdeklarationen betyder, strunta i det, man måste inte förstå det för denna uppgift. Ett exempel på användning finns i (den något artificiella) klassen MinAndSize (fig. 10, sid. 9). 4.1 Publika instansvariabler? Klassen Pair har publika instansvariabler. Detta bryter rimligtvis mot god sed med avseende på inkapsling och synlighet. Ställer detta till det på något vis i Pairklassen? 4.2 Vad gör final? Variablerna first och second är deklarerade final. Vad är den tänkta klassinvarianten (formulera informellt) och kan man garantera att den håller? Jämför gärna med uppgift 3 från vecka 3:s övning. Referenser [Blo08] Joshua Bloch. Effective Java. Addison-Wesley, 2nd edition, 2008. 2 Se t.ex. http://en.wikipedia.org/wiki/tuple 7

* Immutable class for generic pairs. * @inv State your expected invariant(s) here. public final class Pair<A, B> { * The first element of the pair. public final A first; * The second element of the pair. public final B second; * Makes a new pair of type <A,B>. * * @param first the first element of the pair. * @param second the second element of the pair. public Pair(final A first, final B second) { this.first = first; this.second = second; @Override public boolean equals(final Object o) { return o instanceof Pair<?,?> && ((Pair<?,?>) o).first.equals(this.first) && ((Pair<?,?>) o).second.equals(this.second); @Override public int hashcode() { return this.first.hashcode() * 13579 + this.second.hashcode() * 23456789; @Override public String tostring() { return "Pair: <" + this.first.tostring() + "," + this.second.tostring() + ">"; Figur 9: Klassen Pair. 8

public class MinAndSize<E extends Comparable<E>> { * Returns a pair containing the number of elements and the minimum element * of an iterable collection. public Pair<Integer, E> minandsize(final Iterable<E> elements) { final Iterator<E> it = elements.iterator(); if (!it.hasnext()) { throw new IllegalArgumentException("min and max undefined for empty sets."); E min = it.next(); int i = 0; while (it.hasnext()) { E e = it.next(); if (e.compareto(min) < 0) { min = e; i++; return new Pair<Integer, E>(Integer.valueOf(i), min); public static void main(final String[ ] args) { MinAndSize<String> m = new MinAndSize<String>(); Pair<Integer, String> p = m.minandsize(arrays.aslist(args)); System.out.println("Elements: " + p.first + " Min: " + p.second); Figur 10: Klassen MinAndSize. 9