JAVA EFFICACE

Monday, November 5, 12
agenda
création et destruction d’objet
méthodes communes
classes et interfaces
méthodes
exceptions
threads
...

Monday, November 5, 12
création et destruction d’objet

Monday, November 5, 12
création et destruction d’objet

Privilégier des méthodes de fabrique statiques aux constructeurs :
public static Boolean valueOf(boolean b) {
return (b? Boolean.TRUE : Boolean.FALSE);
}
■
■
■
■

Posséde un nom
Pas d’obligation de créer un nouvel objet à chaque fois
Permet d’envoyer des objets de tout type
Utiliser valueOf ou getInstance

Monday, November 5, 12
création et destruction d’objet

Eviter les finaliseurs
void finalize() {
try {
// finalise l’état
finally {
super.finalize();
}
}

■ Utiliser plutôt une méthode public explicite de fermeture des ressources

Monday, November 5, 12
méthodes communes

Monday, November 5, 12
méthodes communes
Obéir au contrat général lors d’une redéfinition de la méthode equals
@Override
public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
Object other = obj;
if (attribut == null) {
if (other. attribut != null)
return false;
} else if (!attribut.equals(other.attribut))
return false;
return true;
}

■ Quand définir equals ?
■ L’égalité logique différe de l’égalité d’objet
■ Si non redéfinit par une classe parente

Monday, November 5, 12
méthodes communes
Toujours redéfinir hashCode lorsque equals est redéfini

@Override
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + ((attr == null) ? 0 : attr.hashCode());
return result;
}

■ Des objets égaux doivent avoir des codes de hashage égaux

Monday, November 5, 12
méthodes communes
Toujours redéfinir toString

@Override
public String toString() {
StringBuilder builder = new StringBuilder();
builder.append("Objet [attr=").append(attr).append("]");
return builder.toString();
}

■ Rend l’utilisation plus aggréable
■ Doit renvoyer toutes les informations interressantes contenues dans l’objet

Monday, November 5, 12
méthodes communes
Envisager l’implémentation de Comparable

@Override
public int compareTo(Objet o) {
ChaineInsensibleCasse cic = (ChaineInsensibleCasse)o;
return String.CASE_INSENSITIVE_ORDER.compare(this.s,cis.s);
}

■ Utilisé par Collections.sort()

Monday, November 5, 12
classes et interfaces

Monday, November 5, 12
classes et interfaces
Restreindre l’accès des classes et de leurs membres
public class MyCoolObject {
private char[] attr0;
int attr1;
protected String attr2;
public String attr3;
...
}

■ Rendre chaque classe ou membre aussi innaccessible que
possible (régle de base)
■ privé, privée paquetage, protégé, public
■ Ne jamais avoir un tableau public et static

Monday, November 5, 12
classes et interfaces
Favoriser l’immutabilité
■ Une classe immuable est tout simplement une classe dont les instances
ne peuvent pas être modifiées. Elle est figée lors de la création. (ex:
String, BigInteger, BigDecimal, ...)
■ Exelente brique de base pour d’autres objets
■ Comment faire ?
■ Ne pas fournir de méthode susceptible de modifier l’objet
■ S’assurer qu’aucune méthode ne peut être redéfinie
■ Rendre finaux tout les champs
■ Rendre privée tout les attributs
■ Garantir l’accés exclusif à tout composant muable

Monday, November 5, 12
classes et interfaces

■
■
■
■

Préférer la composition à l’héritage
Prévoir et documenter l’héritage ou bien l’interdire
Préférer les interfaces aux classes abstraites
N’utiliser les interfaces que pour définir les types

Monday, November 5, 12
méthodes

Monday, November 5, 12
méthodes
Vérifier la validité d’un paramètre
public boolean displayErrors(Set<ConstraintViolation<T>> violations, HasHTML hasHTML){
if (violations == null)
throw new NullPointerException("violations must not be null");
if (hasHTML == null)
throw new NullPointerException("hasHTML must not be null");
if (hasHTML.getHTML().isEmpty())
throw new IllegalArgumentException("hasHTML.html must not be empty");
...
}

■ A faire au début d’une méthode
■ NPE, IAE, ISE, IOOBE, UOE, ...

Monday, November 5, 12
méthodes
Renvoyer des tableaux et/ou lists vide plutôt que null
public List<String> getMessages(){
final List<String> msgs = new ArrayList<String>();
... // some code (add, ...)
return msgs;
}

■ Plus besoin de traiter le cas “null”

Monday, November 5, 12
méthodes

■ Concevoir avec attention la signature d’une méthode
■ Ecrire des commentaires de documentation pour tous les
éléments exposés d’une API

Monday, November 5, 12
exceptions

Monday, November 5, 12
exceptions
Préférer l’utilisation d’une exception standard
public void method(int i) throws Exception{
if(i<0) throw new IllegalArgumentException(“message”);
try {
// ...
} catch (IOException) {
// situation récupérable
}
}

■ Runtime exception : NPE, ...
■ Exception vérifié : IOE, ...
■ Utiliser une exception vérifiée pour une situation récupérable et une exception non
vérifié pour une erreur de programmation
■ Ne pas ignorer une exception

Monday, November 5, 12
thread

Monday, November 5, 12
threads

■
■
■
■

Monday, November 5, 12

Synchroniser l’accès à toute donnée partagée et muable
Eviter toute synchronisation excessive
Ne jamais invoquer wait en dehors d’une boucle
Eviter les groupes de threads
programmation générale (conclusion)

■
■
■
■
■
■
■
■

Monday, November 5, 12

Minimiser la portée des variables locales
Connaître et utiliser les bibliothèques
Eviter float et double si un résultat exact est requis
Eviter les chaînes de caractères là où d’autres types sont
plus appropriés
Attention à la performance dans la concaténation de chaînes
de caractères
Faire référence à un objet via son interface
Préférer les interfaces à la réflection
Suivre les conventions de nommage généralement acceptées
Monday, November 5, 12

Java Efficace

  • 1.
  • 2.
    agenda création et destructiond’objet méthodes communes classes et interfaces méthodes exceptions threads ... Monday, November 5, 12
  • 3.
    création et destructiond’objet Monday, November 5, 12
  • 4.
    création et destructiond’objet Privilégier des méthodes de fabrique statiques aux constructeurs : public static Boolean valueOf(boolean b) { return (b? Boolean.TRUE : Boolean.FALSE); } ■ ■ ■ ■ Posséde un nom Pas d’obligation de créer un nouvel objet à chaque fois Permet d’envoyer des objets de tout type Utiliser valueOf ou getInstance Monday, November 5, 12
  • 5.
    création et destructiond’objet Eviter les finaliseurs void finalize() { try { // finalise l’état finally { super.finalize(); } } ■ Utiliser plutôt une méthode public explicite de fermeture des ressources Monday, November 5, 12
  • 6.
  • 7.
    méthodes communes Obéir aucontrat général lors d’une redéfinition de la méthode equals @Override public boolean equals(Object obj) { if (this == obj) return true; if (obj == null) return false; if (getClass() != obj.getClass()) return false; Object other = obj; if (attribut == null) { if (other. attribut != null) return false; } else if (!attribut.equals(other.attribut)) return false; return true; } ■ Quand définir equals ? ■ L’égalité logique différe de l’égalité d’objet ■ Si non redéfinit par une classe parente Monday, November 5, 12
  • 8.
    méthodes communes Toujours redéfinirhashCode lorsque equals est redéfini @Override public int hashCode() { final int prime = 31; int result = 1; result = prime * result + ((attr == null) ? 0 : attr.hashCode()); return result; } ■ Des objets égaux doivent avoir des codes de hashage égaux Monday, November 5, 12
  • 9.
    méthodes communes Toujours redéfinirtoString @Override public String toString() { StringBuilder builder = new StringBuilder(); builder.append("Objet [attr=").append(attr).append("]"); return builder.toString(); } ■ Rend l’utilisation plus aggréable ■ Doit renvoyer toutes les informations interressantes contenues dans l’objet Monday, November 5, 12
  • 10.
    méthodes communes Envisager l’implémentationde Comparable @Override public int compareTo(Objet o) { ChaineInsensibleCasse cic = (ChaineInsensibleCasse)o; return String.CASE_INSENSITIVE_ORDER.compare(this.s,cis.s); } ■ Utilisé par Collections.sort() Monday, November 5, 12
  • 11.
  • 12.
    classes et interfaces Restreindrel’accès des classes et de leurs membres public class MyCoolObject { private char[] attr0; int attr1; protected String attr2; public String attr3; ... } ■ Rendre chaque classe ou membre aussi innaccessible que possible (régle de base) ■ privé, privée paquetage, protégé, public ■ Ne jamais avoir un tableau public et static Monday, November 5, 12
  • 13.
    classes et interfaces Favoriserl’immutabilité ■ Une classe immuable est tout simplement une classe dont les instances ne peuvent pas être modifiées. Elle est figée lors de la création. (ex: String, BigInteger, BigDecimal, ...) ■ Exelente brique de base pour d’autres objets ■ Comment faire ? ■ Ne pas fournir de méthode susceptible de modifier l’objet ■ S’assurer qu’aucune méthode ne peut être redéfinie ■ Rendre finaux tout les champs ■ Rendre privée tout les attributs ■ Garantir l’accés exclusif à tout composant muable Monday, November 5, 12
  • 14.
    classes et interfaces ■ ■ ■ ■ Préférerla composition à l’héritage Prévoir et documenter l’héritage ou bien l’interdire Préférer les interfaces aux classes abstraites N’utiliser les interfaces que pour définir les types Monday, November 5, 12
  • 15.
  • 16.
    méthodes Vérifier la validitéd’un paramètre public boolean displayErrors(Set<ConstraintViolation<T>> violations, HasHTML hasHTML){ if (violations == null) throw new NullPointerException("violations must not be null"); if (hasHTML == null) throw new NullPointerException("hasHTML must not be null"); if (hasHTML.getHTML().isEmpty()) throw new IllegalArgumentException("hasHTML.html must not be empty"); ... } ■ A faire au début d’une méthode ■ NPE, IAE, ISE, IOOBE, UOE, ... Monday, November 5, 12
  • 17.
    méthodes Renvoyer des tableauxet/ou lists vide plutôt que null public List<String> getMessages(){ final List<String> msgs = new ArrayList<String>(); ... // some code (add, ...) return msgs; } ■ Plus besoin de traiter le cas “null” Monday, November 5, 12
  • 18.
    méthodes ■ Concevoir avecattention la signature d’une méthode ■ Ecrire des commentaires de documentation pour tous les éléments exposés d’une API Monday, November 5, 12
  • 19.
  • 20.
    exceptions Préférer l’utilisation d’uneexception standard public void method(int i) throws Exception{ if(i<0) throw new IllegalArgumentException(“message”); try { // ... } catch (IOException) { // situation récupérable } } ■ Runtime exception : NPE, ... ■ Exception vérifié : IOE, ... ■ Utiliser une exception vérifiée pour une situation récupérable et une exception non vérifié pour une erreur de programmation ■ Ne pas ignorer une exception Monday, November 5, 12
  • 21.
  • 22.
    threads ■ ■ ■ ■ Monday, November 5,12 Synchroniser l’accès à toute donnée partagée et muable Eviter toute synchronisation excessive Ne jamais invoquer wait en dehors d’une boucle Eviter les groupes de threads
  • 23.
    programmation générale (conclusion) ■ ■ ■ ■ ■ ■ ■ ■ Monday,November 5, 12 Minimiser la portée des variables locales Connaître et utiliser les bibliothèques Eviter float et double si un résultat exact est requis Eviter les chaînes de caractères là où d’autres types sont plus appropriés Attention à la performance dans la concaténation de chaînes de caractères Faire référence à un objet via son interface Préférer les interfaces à la réflection Suivre les conventions de nommage généralement acceptées
  • 24.