”Effective Java” præsentation

1. ”Effective Java” præsentation Hvid gruppe: Jesper, Peter, Kasper og Anna

2. Item 24 - Eliminate unchecked warnings • Wrong: Venery.java:4: warning: [unchecked] unchecked conversion found : HashSet, required: Set<Lark> Set<Lark> exaltation = new HashSet(); • Right: Set<Lark> exaltation = new HashSet<Lark>(); • Generally good to explicitly define which elements to hold – ensures type safety! • Avoids down-casting at a later point – less error prone.

3. Item 24 • Wrong: Venery.java:4: warning: [unchecked] unchecked conversion found : HashSet, required: Set<Lark> Set<Lark> exaltation = new HashSet(); • Stop-gap solution: @SuppressWarnings(”unchecked”) Set<Lark> exaltation = new HashSet();

4. Item 24 • Most errors can be fixed, suppressing warnings is a symptom of bad design. • Restrict usage to the smallest scope possible. Remember: Using suppression leads to the path of the dark side!

5. Item 40 - Design method signatures carefully • Wrong: public ResultSetexecuteStatement(String dbDriver, String dbHostname, String dbDatabase, String dbUsername, String dbPassword, String dbStatement) { throws SQLException, ClassNotFoundException ... } • Too many parameters - impossible to remember! • All are the same type, no compile errors if parameters are mixed up - just unexpected results!

6. Item 40 • Right: ConnectionCreator myCon = new ConnectionCreator.Builder( "mysql", "mysql.itu.dk").setUserName("JoeSixPack") .setPassword("mySuperSecretPasswordSsssh!").build(); • Still suffers from the one-liner complex. • No need to worry about the order of the parameters.

7. Item 40 • Choose method names carefully – follow name conventions (item 56) for better maintainability. • Avoid too many methods in a single class – find a balance between too many methods and too long methods. • Avoid too many parameters – no more than four per method. Use helper classes (item 22), divide into smaller methods or use builder patterns (item 2).

8. Item 40 • Use interface types instead of class types as parameters – if your method takes a list as an argument don’t require an ArrayList just List. • Prefer two-element enum types to boolean parameters – easier to read, easier to add more options later.

9. Item 48 - Avoid float and double if exact answers are required • Wrong: //Broken – uses floating point for monetary calculation! public static void main(String[] args) { double funds = 1.00; int itemsBought = 0; for (double price = .10; funds >= price; price += .10) funds -= price; itemsBought++;} System.out.println(itemsBought + ” items bought.”); System.out.println(”Change: $” + funds); Output: 3 items bought. Change: $0.3999999999

10. Item 48 • Right: public static void main(String[] args) { final BigDecimal TEN_CENTS = new BigDecimal(”.10”); int itemsBought = 0; BigDecimal funds = new BigDecimal(”1.00”) for(BigDecimal price = TEN_CENTS; funds.compareTo(price) >= 0; price = price.add(TEN_CENTS)){ funds = funds.substract(price); itemsBought++;} System.out.println(itemsBought + ” items bought.”); System.out.println(”Change: ” + funds + ”cents”);} Output: 4 items bought Change: 0.00 cents

11. Item 64 - Strive for failure atomicity • A failed method should leave the object in the state it was prior to the invocation. • Use immutable objects – objects that can’t be changed. • Make sure to execute any statements that might raise an error before committing the changes.

12. Item 8: Obey the general contract when overriding equals • Never override equals unless you need a logical equality test – and if you do RTFM! Item 16: Favor composition over inheritance • Selective interface exposure – inheritance never allows narrowing the interface. • Composition allows significant changes to the implementation of the composite element.

13. Item 32: Use EnumSet instead of bit fields • EnumSets allows you to combine several constants into a set known as a bit field. • EnumSets handle the implementation that you would otherwise have to do yourself. Item 56: Adhere to generally accepted naming conventions • Refer to page 238 for a quick table of naming conventions for packages, classes, methods etc.