TDA550 Objektorienterad programvaruutveckling IT, forts. kurs Övning vecka 2 Pelle Evensen, Daniel Wetterbro 5 november 2009 Sammanfattning Denna vecka ska vi titta på abstrakta klasser kontra interface, polymorfism, dynamisk bindning, equals samt (mycket) lite om klassinvarianter. Ö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 Design 1.1 Snygg design? Jan 1 har byggt ett fint spel där man ska döda varelser. Som tur var insåg han tidigt i utvecklingen av spelet att strukturen nedan skulle vara mindre lyckad då man kan tänkas vilja lägga till fler varelser och beteenden. Diskutera vilka nackdelar som finns med strukturen i klasserna Creature (fig. 1) och Gang (fig. 2). Skriv om koden så att man blir av med de problem ni identifierat. Kan abstrakta klasser eller interface vara till någon hjälp? I så fall, vilket borde man välja? Vill eller kan man kombinera dem? 1 Problemet lånat från tenta av Jan Skansholm. 1
public class Gang { private List<Creature> members; public Gang(int size) { members = new ArrayList<Creature>(size); public void add(creature m) { members.add(m); public class Creature { public enum Type { SNAKE, GOBLIN, SPIDER ; private Type type; private int energy = 100; private String name; public Creature(String n, Type t) { this.name = n; this.type = t; public Type gettype() { return type; public int getenergy() { return energy; public boolean remove(creature m) { return members.remove(m); public int damagesum() { int total = 0; for (Creature c : members) { if (c!= null) { int energy = c.getenergy(); switch (c.gettype()) { case SNAKE: total += 10 * energy; break; case GOBLIN: total += 4 * energy * energy; break; case SPIDER: if (energy > 5) total += 100; break; public void setenergy(int e) { this.energy = e; public String getname() { return name; Figur 1: Klassen Creature. return total; public static void main(string[ ] args) { Creature snake = new Creature("Sour Serpent", Creature.Type.SNAKE); Creature goblin = new Creature("Greasy Goblin", Creature.Type.GOBLIN); Creature spider = new Creature("Spicy Spider", Creature.Type.SPIDER); Gang gang = new Gang(3); gang.add(snake); gang.add(spider); gang.add(goblin); System.out.println("Collective damage: " + gang.damagesum()); Figur 2: Klassen Gang. 2
1.2 Abstrakta klasser eller interface? I fig. 3 fig. 8 har vi kod 2 för sex klasser som representerar olika typer av former: cirkel, rektangel och kvadrat. Varje typ finns dessutom i två varianter, en muterbar och en icke-muterbar. Operationer för att sätta (i vissa fall bara genom konstruktorn) och beräkna egenskaper finns också implementerade i varje klass. Försök att generalisera klassernas struktur genom att använda gränssnitt och/eller abstrakta klasser. Vilka operationer/attribut är unika för varje typ och vilka gäller för alla? Glöm inte att ta hänsyn till muterbarhet. Varför är det inte så lyckat att ha dem utan gemensamma basklasser eller gränssnitt? public class ImmutableCircle { private final double radius; public ImmutableCircle(double r) { this.radius = r; public double getradius() {... public class MutableCircle { private double radius; public MutableCircle(double r) { this.radius = r; public double getradius() {... return Math.PI * radius * radius; return 2 * Math.PI * radius; Figur 3: Klassen ImmutableCircle. public void setradius(double r) {... return Math.PI * radius * radius; return 2.0 * Math.PI * radius; Figur 4: Klassen MutableCircle. 2 Vi har av platsskäl tagit bort koden för några av de uppenbara accessorerna/mutatorerna och ersatt med.... 3
public class ImmutableRectangle { private final double height, width; public ImmutableRectangle(double h, double w) { this.height = h; this.width = w; public double getheight() {... public double getwidth() {... return height * width; public class MutableRectangle { private double height, width; public MutableRectangle(double h, double w) { this.height = h; this.width = w; public double getheight() {... public double getwidth() {... public void setheight(double h) {... public void setwidth(double w) {... return 2 * height + 2 * width; Figur 5: Klassen ImmutableRectangle. return height * width; return 2 * height + 2 * width; Figur 6: Klassen MutableRectangle. public class ImmutableSquare { private final double side; public ImmutableSquare(double s) { this.side = s; public double getside() {... public class MutableSquare { private double side; public MutableSquare(double s) { this.side = s; public double getside() {... return side * side; return 4 * side; Figur 7: Klassen ImmutableSquare. public void setside(double s) {... return side * side; return 4 * side; Figur 8: Klassen MutableSquare. 4
2 Klassinvarianter Klassen Period representerar ett datumintervall genom att innehålla ett startdatum och ett slutdatum. I kommentarerna till klassen visas dessutom vilket kontrakt implementationen av klassen måste uppfylla ( Programming by Contract ). En invariant är ett villkor som alltid måste vara uppfyllt, ett precondition utgör krav som måste vara uppfyllda innan en metod anropas och postcondition visar samband som gäller efter att metoden körts. Några klassinvarianter för Period (vilka?) medför att klassen är icke-muterbar. Har programmeraren gjort sitt jobb eller finns det sätt att bryta mot klassens invarianter? Om så är fallet, hur kan vi åtgärda felen? /** * @invariant getstart() is before or at the same time as getend() * @invariant getstart() consistently returns the same value after object creation * @invariant getend() consistently returns the same value after object creation */ public final class Period { private final Date start; private final Date end; /** * @param start the beginning of the period * @param end the end of the period; must not precede start * @pre start <= end * @post The time span of the returned period is positive. * @throws IllegalArgumentException if start is after end * @throws NullPointerException if start or end is null */ public Period(Date start, Date end) { if (start.compareto(end) > 0) { throw new IllegalArgumentException(start + " after " + end); this.start = start; this.end = end; public Date getstart() { return start; public Date getend() { return end; Figur 9: Klassen Period. 5
3 Polymorfism och dynamisk typ Klassen Binding (fig. 10) innehåller metoder för utskrift av olika typer av objekt. Alla klasser i Java är subklasser till klassen Object som innehåller metoden tostring(). Metoden printvalue är överlagrad och skiljer sig bara med avseende på typen hos den formella parametern. Vad kommer utskriften att bli? Vilka metoder kommer att exekveras vid körningen av main och framförallt; varför anropas just de metoderna? public class Binding { public static void printvalue(integer i) { System.out.println("I m an Integer valued " + i + "."); public static void printvalue(string s) { System.out.println("I m a String containing \"" + s + "\"."); public static void printvalue(object o) { System.out.println("I m a " + o.getclass() + ": " + o + "."); public static void main(string[ ] args) { Object[ ] objs = new Object[ ] { new Integer(3), new String("Hej hej!"), new Double(0.1) ; for (Object o : objs) { printvalue(o); Figur 10: Klassen Binding. 6
4 Likhet (equals) För metoden equals förväntar vi oss typiskt att dessa egenskaper håller; Reflexivitet: a.equals(a) Symmetri: a.equals(b) = b.equals(a) Transitivitet: a.equals(b) b.equals(c) = a.equals(c) 4.1 Relationsdrama 3 I Betrakta klassen CaseInsensitiveString (fig. 11). Finns det några omständigheter under vilka de tre önskvärda relationerna inte gäller för klassen? Vad händer om man jämför med en String? Med en CaseInsensitiveString? Spelar ordningen någon roll? Om det finns något problem, vad borde man gjort istället? public final class CaseInsensitiveString { private final String s; public CaseInsensitiveString(String s) { if (s == null) { throw new NullPointerException(); this.s = s; @Override public boolean equals(object o) { if (o instanceof CaseInsensitiveString) { CaseInsensitiveString cis = (CaseInsensitiveString) o; return s.equalsignorecase(cis.s); else if (o instanceof String) { return s.equalsignorecase((string) o); return false; Figur 11: Klassen CaseInsensitiveString. 3 Lånad från [Blo08] 7
4.2 Relationsdrama II Betrakta klasserna Point (fig. 12) och NamedPoint (fig. 13). Håller relationerna beskrivna i sektion 4 för dessa två klasser? Om inte, vilken eller vilka relationer håller inte och hur borde man implementerat equals istället? public class Point { private final int x; private final int y; public Point(int x, int y) { this.x = x; this.y = y; public class NamedPoint extends Point { private final String name; public NamedPoint(int x, int y, String name) { super(x, y); this.name = name; @Override public boolean equals(object o) { if (!(o instanceof Point)) { return false; else { Point p = (Point) o; return p.x == x && p.y == y; Figur 12: Klassen Point. @Override public boolean equals(object o) { if (!(o instanceof Point)) { return false; // If o is a normal Point, do // a name-blind comparison if (!(o instanceof NamedPoint)) { return o.equals(this); // o is a NamedPoint; do // a full comparison return super.equals(o) && ((NamedPoint) o).name == name; Figur 13: Klassen NamedPoint. Referenser [Blo08] Joshua Bloch. Effective Java. Addison-Wesley, 2nd edition, 2008. 8