Effective Java items Orange gruppe Thuy, Janne, Mads T.P., Oliver og Sebastian

Item 22 - Favor static members classes over nonstatic 1/2 Item 22 diskuterer hvornår og hvilke af de 4 forskellige typer nested classes man skal bruge og at man generelt burde foretrække static over nonstatic. De 4 typer: – Static member classes – Nonstatic member classes – Anonymous classes – Local classes.

Item 22 - Favor static members classes over nonstatic 2/2 Static member classes – Bruges til at være en “hjælper” klasse, som er til gavn i forhold til sin ydre klasse. Den har ikke brug for adgang til sin ydre klasse og spilder ikke plads på at have en ekstra og unødig reference til dens ydre klasse, f.eks: public class NestedClassTip { private String name = "instance name"; private static String staticName = "static name"; public static void main(String args[]) { NestedClassTip nt = new NestedClassTip(); NestedClassTip.NestedOne nco = nt.new NestedOne(); NestedClassTip.NestedTwo nct = new NestedClassTip.NestedTwo(); } class NestedOne { NestedOne() { System.out.println(name); System.out.println(staticName); } } static class NestedTwo { NestedTwo() { System.out.println(staticName); } } }

Item 30 – Brug enums i stedet for int konstanter 1/4 I gamle dage… Nu bruger man Enums Public static final int SEASON_WINTER = 0; Public static final int SEASON_SPRING = 1; Public static final int SEASON_SUMMER = 2; Public static final int SEASON_FALL = 3; public enum Seasons { WINTER, SPRING, SUMMER, FALL; }

Item 30 – Brug enums i stedet for int konstanter 2/4 Enum-værdier med forskellig adfærd er ikke godt public enum TrafficLight{ RED, YELLOW, GREEN; void light(){ switch(this){ case RED: stop(); case YELLOW: lowerSpeed(); case GREEN: go(); } throw new AssertionError(“unknown color: ”+this); }

Item 30 – Brug enums i stedet for int konstanter 3/4 Brug i stedet konstant-specifik metodeimplementationer public enum TrafficLight{ RED{ void light(){ stop(); } }, YELLOW{ void light(){ lowerSpeed(); } }, GREEN{ void light(){ go(); } }; abstract void light(); }

Item 30 – Brug enums i stedet for int konstanter 4/4 Hvorfor så bruge switch? – “Switches on enums are good for augmenting external enum types with constant- specific behavior.” // Switch on an enum to simulate a missing method public static Operation inverse(Operation op) { switch(op) { case PLUS: return Operation.MINUS; case MINUS: return Operation.PLUS; case TIMES: return Operation.DIVIDE; case DIVIDE: return Operation.TIMES; default: throw new AssertionError("Unknown op: "+op); }

Item 38 – Check parameters for validity 1/2 Hvad vil det sige? – At tjekke at alle parametre givet til konstruktorer og metoder er gyldige for at resultatet bliver korrekt. – Fx vil man ofte tjekke at at der ikke er angivet nogen null-pointere, da det vil give runtime fejl senere i metoden hvis der kaldes metoder på objektet. – En int parameter skal ofte have en værdi inden for et vist interval, eller fx bare være ikke-negativ (et index fx). Hvorfor er det vigtigt? – Jo tidligere man kan opsnappe fejl, jo nemmere bliver det at finde årsagen til fejl. – Værre er det hvis der ikke opstår nogen direkte fejl, og metoden returnerer et forkert/ugyldigt resultat. Således vil problemet blive kastet videre. – Værst er det hvis man efterlader et objekt i en ugyldig tilstand. Fx kan et Month objekt pludselig have værdien 13. Hvornår behøver man ikke gøre det? – Hvis tjekket er unødvendigt upraktisk. – Eller hvis selve udførslen af metoden vil opfange fejlen. – Hvis en metode fx sammenligner en række objekter, kræves det at objekterne er sammenlignelige. Der vil blive kastet en ClassCastException hvis der sker en ugyldig sammenligning.

Item 38 – Check parameters for validity 1/2 To eksempler på gyldighedstjek af parametre: /* IndexOutOfBoundsException if index is out of bounds */ public ListItem getItemAt(int index) { if (index this.size()) { throw new IndexOutOfBoundsException(); } …continue method } /* IllegalArgumentException if one of the objects are null */ public double calculateDistance(Point p1, Point p2) { if (p1 == null || p2 == null) { throw new IllegalArgumentException(); } …continue method }

Item 62 – Dokumenter alle exceptions kastet af hver metode 1/2 Dokumenter altid checked exceptions og unchecked exceptions individuelt ved hver metode ved brug af tag. – Programmøren bliver kendt med de fejl der kan laves og kan hermed undgå dem. Samme exception i flere metoder, så er det fint nok bare at skrive i kommentarerne: – Fx NullPointerException, “All methods in this class throw a NullPointerException if a null object reference is passed in any parameter,” eller lign.

Item 62 – Dokumenter alle exceptions kastet af hver metode 1/2 Eksempel på dokumentation af exceptions

Item 6 - Eliminate obsolete object references Aka unintentional object retention Hvad er det ? – a reference which “is no longer reachable by the program, but still considered reachable by the garbage collector” Eks. pop() Hvornår skal man være opmærksom på memory leak? Hvordan eliminerer man obsolete object referencer? – Nulling – Minimaliser scope (Item 45 – gruppe rød) Other sources for memory leak: caches, listeners and other callbacks

Item 14 - In public classes, use accessor methods, not public fields Jævnfør 1. forelæsning i Bosk om indkapsling Hvornår er det mere i orden at bruge public felter? – Immutable felter – Package-private klasser – Private nested klasser

Item 46 - Prefer for-each loops to traditional for loops Hvorfor? – Pladsbesparelse og mindre mulighed for fejl Hvorfor ikke? – Mindre fleksibilitet – Filtrering – Transformering – Parallel iteration

Item 54 - Use native methods judiciously Hvad er det? – “Special methods written in native programming languages such as C or C++” Hvorfor bliver de brugt? – Adgang til platform-specifikke faciliteter (registries og file locks). – Adgang til libraries of legacy code – Forbedret performance. Hvorfor skal man ikke bruge dem? – Mindre sikkerhed -> memory corruption errors. – Mindre transportable – Svære at debugge – Det koster performance at gå ind og ud af native code – Kræver “glue code”