Java Efficace

JAVA EFFICACE

Monday, November 5, 12

agenda

création et destruction d’objetméthodes communesclasses et interfaces

méthodesexceptions

threads...


création et destruction d’objet


Privilégier des méthodes de fabrique statiques aux constructeurs :


■ 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

public static Boolean valueOf(boolean b) { return (b? Boolean.TRUE : Boolean.FALSE);}


Eviter les finaliseurs


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

void finalize() { try {

// finalise l’étatfinally { super.finalize();}

}


méthodes communes


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

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; }


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

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; }


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

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(); }


■ Utilisé par Collections.sort()

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); }


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



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



■ 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


méthodes


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, ...


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”


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


exceptions


exceptions

Préférer l’utilisation d’une exception standard

■ 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

public void method(int i) throws Exception{ if(i<0) throw new IllegalArgumentException(“message”); try { // ... } catch (IOException) { // situation récupérable }}


thread


threads

■ 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)

■ 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



Technology

Java Efficace