effective java

Presentation of the Joshua Bloch's Book.

www.supinfo.com

Copyright © SUPINFO. All rights reserved

Effective Java

The Speaker

- Bug Out PC- ADF- Adullact- Webpulser- Audaxis

- Groupe Open- Atos Worldline- Xebia IT

Brice Argenson

Effective Java

- 59253@supinfo.com brice.argenson @bargenson

Professional Experiences:

Training:- DUT Informatique / Montpellier- Supinfo B3 / Montpellier- Supinfo M1 / Lille- STA Java Lille / Valenciennes

Certifications:- SCJP 6

- SCWCD 5

Agenda

Develop more effectively ?

Creating and Destroying objects

Classes and Interfaces

Methods

General Programming

The Book

About the Author

Effective Java

Develop more effectively ?

Good practices

Effective Java

Creating and Destroying objectsDevelop more effectively ?

Public constructor is the normal way for a class to allow a client to obtain an instance of itself.

Another technique is to provide a public static factory method !

Item 1: Consider static factory methods instead of constructors.

Creating and Destroying objectsDevelop more effectively ?

First advantage : They have names !

BigInteger(int bitLength, int certainty, Random rnd)

Constructs a randomly generated positive BigInteger that is probably prime, with the specified bitLength.

BigInteger.probablePrime(int bitLength, Random rnd)

Returns a positive BigInteger that is probably prime, with the specified bitLength.

Item 1: Consider static factory methods instead of constructors.

Creating and Destroying objectsDevelop more effectively ?

Second advantage : They are no required to create a new object each time they’re invoked.

Item 1: Consider static factory methods instead of constructors.

Creating and Destroying objectsDevelop more effectively ?

Third advantage : They can return an object of any subtype of their return type.

Item 1: Consider static factory methods instead of constructors.

Creating and Destroying objectsDevelop more effectively ?

Fourth advantage : They reduce the verbosity of creating parameterized type instances.

Item 1: Consider static factory methods instead of constructors.

Creating and Destroying objectsDevelop more effectively ?

First disadvantage : Classes without public or protected constructors cannot be sub-classed.

Second disadvantage : They are not readily distinguishable from other static methods.

Item 1: Consider static factory methods instead of constructors.

Creating and Destroying objectsDevelop more effectively ?

Static factories and constructors share a limitation: they don’t scale well to large members of optional parameters.

Traditionally, two patterns are used :

Telescoping constructor pattern.

JavaBeans pattern.

Item 2: Consider a builder when faced with many constructor parameters.

Creating and Destroying objectsDevelop more effectively ?

Creating and Destroying objectsDevelop more effectively ?

Telescoping constructor pattern :

Hard to write.

Harder to read :

Item 2: Consider a builder when faced with many constructor parameters.

Creating and Destroying objectsDevelop more effectively ?

Creating and Destroying objectsDevelop more effectively ?

JavaBeans pattern :

Easier to write.

Easier to read :

But JavaBean may be in an inconsistent state partway through its construction !

Item 2: Consider a builder when faced with many constructor parameters.

Creating and Destroying objectsDevelop more effectively ?

Creating and Destroying objectsDevelop more effectively ?

Builder pattern :

Easy to write.

Easy to read :

Simulates named optional parameters.

Consistent state control.

Item 2: Consider a builder when faced with many constructor parameters.

Creating and Destroying objectsDevelop more effectively ?

Is this statement correct ?

Item 5: Avoid creating unnecessary objects.

Creating and Destroying objectsDevelop more effectively ?

Improved version :

Item 5: Avoid creating unnecessary objects.

Creating and Destroying objectsDevelop more effectively ?

Is this code correct ?

Item 5: Avoid creating unnecessary objects.

Creating and Destroying objectsDevelop more effectively ?

Improved version (about 250 times faster for 10 million invocations) :

Item 5: Avoid creating unnecessary objects.

Creating and Destroying objectsDevelop more effectively ?

Is this code correct ?

Item 5: Avoid creating unnecessary objects.

Creating and Destroying objectsDevelop more effectively ?

Improved version (6.3 times faster) :

Item 5: Avoid creating unnecessary objects.

Classes and InterfacesDevelop more effectively ?

Inheritance is a powerful way to achieve code reuse

But not always the best !

Inheritance from ordinary concrete classes across package boundaries is dangerous !

Unlike method invocation, inheritance violates encapsulation.

Item 16: Favor composition over inheritance.

Classes and InterfacesDevelop more effectively ?

Item 16: Favor composition over inheritance.

What this code display ?

Classes and InterfacesDevelop more effectively ?

Item 16: Favor composition over inheritance.

Classes and InterfacesDevelop more effectively ?

Item 16: Favor composition over inheritance.

Classes and InterfacesDevelop more effectively ?

Item 16: Favor composition over inheritance.

Classes and InterfacesDevelop more effectively ?

Design of the InstrumentedSet is extremely flexible :

Implement the Set interface.

Receive an argument also of type Set.

With inheritance, we could work only with HashSet.

With composition, we can work with any Set implementation !

Item 16: Favor composition over inheritance.

Classes and InterfacesDevelop more effectively ?

Classes and InterfacesDevelop more effectively ?

Item 20: Prefer class hierarchies to tagged classes.

Tagged classes are verbose, error-prone, inefficient and just a pallid imitation of a class hierarchy.

Here is the class hierarchy corresponding to the original class :

Classes and InterfacesDevelop more effectively ?

Item 20: Prefer class hierarchies to tagged classes.

Classes and InterfacesDevelop more effectively ?

Item 20: Prefer class hierarchies to tagged classes.

Class hierarchies are more flexible and provide better compile-time type checking.

Suppose we need a square shape :

MethodsDevelop more effectively ?

Consider the following class :

MethodsDevelop more effectively ?

Consider the following code :

Do you see the problem ?

MethodsDevelop more effectively ?

To protect the internals of a Period instance from this sort of attack:

You must make defensive copy of each mutable parameter to the constructor !

Item 39: Make defensive copies when needed.

MethodsDevelop more effectively ?

What does the following program prints ?

Item 41: Use overloading judiciously.

MethodsDevelop more effectively ?

The program print : “Unknown Collection” three times.

The choice of which overloading to invoke is made at compile time !

Not like overridden methods…

Item 41: Use overloading judiciously.

MethodsDevelop more effectively ?

What does the following program prints ?

Item 41: Use overloading judiciously.

MethodsDevelop more effectively ?

The program print : [-3, -2, -1] [-2, 0, 2].

The remove method is overloaded inside List class :

remove(E) : delete the E element inside the list.

remove(int) : delete the element at the specified position.

Item 41: Use overloading judiciously.

MethodsDevelop more effectively ?

Refrain from overloading methods with multiple signatures that have the same number of parameters.

If you can’t, at least avoid situations where the same set of parameters can be passed to different overloadings by the addition of casts.

Item 41: Use overloading judiciously.

General ProgrammingDevelop more effectively ?

What does the following program prints ?

Item 48: Avoid float and double if exact answers are required.

General ProgrammingDevelop more effectively ?

It prints you can afford 3 items and you have $0.3999999999999999 left…

The float and double types are designed primarily for scientific and engineering calculations.

They perform binary floating-point arithmetic with approximations !

They should not be used where exact results are required.

Item 48: Avoid float and double if exact answers are required.

General ProgrammingDevelop more effectively ?

A correct version of the previous program :

Item 48: Avoid float and double if exact answers are required.

General ProgrammingDevelop more effectively ?

“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!):

Don't do it yet.”

- Michael A. Jackson

Item 55: Optimize judiciously.

“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.”

- Donald E. Knuth

"More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any

other single reason - including blind stupidity."

- W.A. Wulf

General ProgrammingDevelop more effectively ?

Strive to write good programs rather than fast ones.

Strive to avoid design decisions that limit performance.

Consider the performance consequence of your API design decisions.

Measure performance before and after each attempted optimization.

Item 55: Optimize judiciously.

The Book

For all the other tips !

Effective Java

The original versionThe Book

Effective JavaSecond Edition

Joshua BLOCH

Addison Wesley editions

"I sure wish I had this book ten years ago. Some might think that I don't need any Java books, but I need this one.”

- James Gosling, Fellow and Vice President, Sun Microsystems, Inc.

The translated versionThe Book

Java EfficaceGuide de programmation

Joshua BLOCH

Traduction d’Alexis Moussine-Pouchkine

Vuilbert editions

http://www.amazon.fr/Java-efficace-Bloch/dp/2711748057/ref=sr_1_1?ie=UTF8&s=books&qid

=1298567425&sr=8-1

About the Author

For all the other tips !

Effective Java

Joshua BlochAbout the Author

http://googleresearch.blogspot.com/ @joshbloch

Chief Java architect at Google.

Jolt Award winner.

Previously a distinguished engineer at Sun Microsystems and a senior systems designer at Transarc.

Led the design and implementation of numerous Java platform features.

BibliographieAbout the Author

Effective Java: Programming Language Guide

ISBN 0201310058, 2001.

Second edition: ISBN 978-0-321-35668-0, 2008.

BibliographieAbout the Author

Java Puzzlers: Traps, Pitfalls, and Corner Cases

ISBN 032133678X, 2005 (co-authored with Neal Gafter).

BibliographieAbout the Author

Java Concurrency in Practice

ISBN 0321349601, 2006 (co-authored with Brian Goetz, Tim Peierls, Joseph Bowbeer, David Holmes, and Doug Lea).

The endEffective Java