Gruppe Grøn

1. Gruppe Grøn Effective Java Items: 4, 12, 20, 28 36, 44, 52, 60

2. Item 4 Enforce noninstantiability with a private constructor • Classes that just group static methods and static fields should not be instantiated • Such classes can be useful -- static methods, including factory methods, implementing an interface, for example • Not designed to be instantiated; instance wouldn’t make sense

3. Item 4 Enforce noninstantiability with a private constructor • Providing no constructor doesn’t work • If noexplicitconstructors, compilerprovides a public, parameterlessdefault constructor • Looks just like any other constructor to clients • Allows for unintentionally instantiable classes • Making a class abstract doesn’t work • Class can be subclassed and subclass can be instantiated • Also misleads user into thinking class was designed for inheritance

4. Item 4 Enforce noninstantiability with a private constructor • Including a private constructor does work • A default constructor is generated only if a class contains no explicit constructors // Noninstantiable utility class public class UtilityClass { // Suppress default constructor for noninstantiability private UtilityClass() { throw new AssertionError(); }

5. Item 4 Enforce noninstantiability with a private constructor • Constructor is private, so inaccessible outside of class • AssertionError not necessary, but flags accidental invocation of constructor from insideclass • Comment helpful since usage counterintuitive • Also prevents class from being subclassed • All constructors must invoke a superclassconstructor • Noaccessiblesuperclassconstructor

6. Item 12 ConsiderimplementingComparable • Comparable is an interface in java.lang package. • It has only one method: compareTo() that compares specific fields of two objects to determine if it is: • less than • equal to • greater than the other object. • It throws ClassCastException if there is a type mismatch.

7. Item 12 ConsiderimplementingComparable • Comparable is useful when: • designing a class with natural ordering of its instances fx age. • When comparing objects of same class according to specified criteria • Sorting of objects into collection framework(Arrays, TreeSet etc.)

8. Item 12 ConsiderimplementingComparable Example of a person class that implement comparable import java.lang.*; // in this example person objects will be compared according to their age public class Person implements Comparable{  String name; int age; Person(...){...} public intcompareTo(Object o){ Person pe = (Person)o; // compares age if (age < pe.age) return -1;  if (age > pe.age) return 1; return 0; } }

9. Item 12 ConsiderimplementingComparable compareTo() vs. equals() All objects have both identity (the object's location in memory) and state (the object's data) The equals method operator tests for • Identity • equality/inequality The CompareTo method operator tests for • If this object is the specified object for order • Returns a negative integer, zero, or a positive integer as this object is less than, equal to, or greater than the specified object. The CompareTo method is similar to equals but needs to satisfy the following conditions: • anticommutation :  • x.compareTo(y) is the opposite sign of y.compareTo(x) • exception symmetry : • x.compareTo(y) throws exactly the same exceptions as y.compareTo(x) • transitivity :  • if x.compareTo(y)>0 and y.compareTo(z)>0, then x.compareTo(z)>0  (and same for less than) • if x.compareTo(y)==0, then x.compareTo(z) has the same sign as y.compareTo(z) • consistency with equals is highly recommended, but not required : • x.compareTo(y)==0, if and only if x.equals(y) ; consistency with equals is required for ensuring sorted collections (such as TreeSet) are well-behaved.

10. Item 12 ConsiderimplementingComparable • Person(...){...} •  public int compareTo(Object o){ •       Person pe = (Person)o; •       return age - pe.age; •   } • }

11. Item 28 Usebounded wildcards to increase API flexibility • Generic types are invariant • That is, List<String> is not a subtype of List<Object> • Good for compile-time type safety, but inflexible • Bounded wildcard types provide additional API flexibilty

12. Item 28 Usebounded wildcards to increase API flexibility • PECS • Producerextends • Consumersuper • For a Tproducer, use Foo<? extends T> • For a Tconsumer, use Foo<? super T> • Only applies to input parameters • Don’t use wildcard types as return types

13. Item 28 Usebounded wildcards to increase API flexibility PECS in Action (1) • Suppose you want to add bulk methods to Stack<E> • void pushAll(Collection<E> src); • void popAll(Collection<E> dst);

14. Item 28 Usebounded wildcards to increase API flexibility PECS in Action (1) • Suppose you want to add bulk methods to Stack<E> • void pushAll(Collection<? extends E> src); • src is an E producer • void popAll(Collection<E> dst);

15. Item 28 Usebounded wildcards to increase API flexibility PECS in Action (1) • Suppose you want to add bulk methods to Stack<E> • void pushAll(Collection<? extends E> src); • src is an E producer • void popAll(Collection<? super E> dst); • dst is an E consumer

16. Item 28 Usebounded wildcards to increase API flexibility PECS in Action (1) • Suppose you want to add bulk methods to Stack<E> • void pushAll(Collection<? extends E> src); • void popAll(Collection<? super E> dst); • User can pushAll from aCollection<Long>or aCollection<Number> onto a Stack<Number> • User can popAll into aCollection<Object>or aCollection<Number> from a Stack<Number>

17. Item 28 Usebounded wildcards to increase API flexibility PECS in Action (2) • Consider this generic method: public static <E> Set<E> union(Set<E> s1, Set<E> s2)

18. Item 28 Usebounded wildcards to increase API flexibility PECS in Action (2) • Consider this generic method: public static <E> Set<E> union(Set<? extends E> s1, Set<? extends E> s2) • Both s1 and s2 are E producers • No wildcard type for return value • Wouldn’t make the API any more flexible • Would force user to deal with wildcard types explicitly • User should not have to think about wildcards to use your API

19. Item 60 Favor the use of standard exceptions • Exceptions: code reuse is good. • The Java platform libraries provide a basic set of unchecked exceptions • Benefits of using preexisting: • API is easier to learn and use • Is easier to read • fewer exception classes mean a smaller memory footprint and less time spent loading classes

20. Item 60 Favor the use of standard exceptions • all erroneous method invocations boil down to an illegal argument or illegal state

21. Item 60 Favor the use of standard exceptions • Others: • ArithmeticException • NumberFormatException • If an exception fits your needs, go ahead and use it • choosing which exception to reuse is not always an exact science

22. Item 52 Refer to objects by their interfaces • Use interfaces rather than classes as parameter types • If appropriate interface types exist, then parameters, return values, variables, and fields should all be declared using interface types. // Good – uses interface as type List<Subscriber> subscribers = new Vector<Subscriber>(); // Bad – uses class as type Vector<Subscriber> subscribers = new Vector<Subscriber>(); List is an interface and Vector is an implementation of the List interface

23. Item 52 Refer to objects by their interfaces • If you get into the habit of using interfaces as types, your program will be much more flexible. • To switch implementations, change the class name in the constructor • List<Subscriber> subscribers = new ArrayList<Subscriber>(); • And all the surrounding code continues to work!

24. Item 36 Consistentlyuse the Override annotation The most important annotation is @Override • It can only be used on method declarations, and indicates override of a supertype

25. Item 36 Consistentlyuse the Override annotation public booleanequals(Bigram b) { return b.first == first && b.second == second; } • To override Object.equals, you must define an equals method whose parameter is of type Object • Bigram is not of type Object and to find errors like that annotations like @Overrides helps the compiler to generate a message like this: Bigram.java:10: method does not override or implement a method from a supertype @Override public boolean equals(Bigram b)

26. Item 36 Consistentlyuse the Override annotation Replace the implementation with this: @Override public boolean equals(Object o) { if(!(o instanceof Bigram)) return false; Bigram b = (Bigram)o; return b.first == first && b.second == second; }

27. Item 36 Consistentlyuse the Override annotation • @Overrides provides help in finding bugs • In abstract class or an Interface it is worth annotating all methods believed to override superclass or superinterface methods. • In concrete classes its not needed to annotate methods that are belived to override abstract method declarations.

28. Item 44 Writedoccomments for all exposed API The Javadoc utility translates doc comments into HTML • {@code} has two purposes • It causes the code fragment to be rendered in code font • And it suppresses processing of HTML markups and nested Javadoc tags in the code fragment (the less than sign <) even though it is an HTML metacharacter.

29. Item 44 Writedoccomments for all exposed API • To generate documentation containing HTML metacharacters (<> and &) the best way is to surround them with • {@literal} it is like the {@code} tag but doesnt render the text in code font. • The triangle inequality is {@literal |x + y| < |x| + |y|}. • Outcome “The triangle inequality is |x + y| < |x| + |y|.”

30. Item 20 Preferclasshierarchies to taggedclasses A classwhoseinstancescome in twoor more and contain a tag fieldindicating the flavor of the instance. classFigure { enumShape { RECTANGLE, CIRCLE }; final Shapeshape; // Tag field - the shape of this figure double length, width; // These fields are used only if shape is RECTANGLE double radius; // This field is used only if shape is CIRCLE Figure(double radius) {shape = Shape.CIRCLE; this.radius = radius;} // Constructor for circle Figure(double length, double width) {shape = Shape.RECTANGLE; this.length = length; this.width = width;} // Constructor for rectangle double area() {switch(shape) { case RECTANGLE:returnlength * width; case CIRCLE:returnMath.PI * (radius * radius); default: throw new AssertionError(); } }

31. Item 20 Preferclasshierarchies to taggedclasses Tagged classes are: • Error-prone, verbose and inefficient. • Instances are burdened with irrelevant fields belonging to other flavors of same instance (circle and square) • Constructors must set tag fields and initialize the right data fields with no help form the compiler