"Un système bien conçu est facile à comprendre, facile à modifier et facile à réutiliser" (in UML for Java programmers, R. C. Martin, ouvrage mentionné ici Références).

Les principales qualités visées par l'approche objet sont la Robustesse, Maintenabilité, Extensibilité et Réutilisabilité.

A eux seuls, les concepts objets ne suffisent pas à produire des logiciels de qualité.

La mise en oeuvre, et le maintien, de ces qualités est assurée par le respect de cetains principes tout au long du cycle de vie du système.

Bien entendu, on peut faire sans ; sans respecter les principes, sans respecter les modèles de réalisation de ces principes, cette "liberté" est représentée par la figure ci-dessous :

Figure 1. Production de code et outils de conception

Alors que les principes décrivent QUOI faire, les designs patterns (modèles de conception) montrent COMMENT le faire, dans un contexte donné. Quant aux frameworks (solution d'architecture applicative), ils démontrent, à leur manière, comment implémenter certains Designs Patterns pour les besoins d'un service générique.

Nous verrons quelques principes fondamentaux, et quelques exemples d'application.

Il est courant de partionner le travail du développeur en 3 activités : l'analyse, la conception et l'implémentation.

En analyse, l'accent est mis sur les responsabiltés des objets et leurs collaborations en vue de répondre à des besoins exprimés, par exemple sous la forme de cas d'utilisation.

En conception, les responsabilités sont traduites en opérations (+ ou - typées). C'est ici que les décisions d'application de modèles de conception (designs patterns), ou d'adoption de frameworks, sont le plus souvent prises (recherche d'une fléxibilité).

Lors de l'activité d'implémentation les tests sont codés (approche test first), les opérations sont traduites en méthodes avec, éventuellement, une décomposition foctionnelle de ces dernières (et introduction de méthodes privées).

Ces activités sont très souvent enchevétrées : ainsi analyse t-on en implémentant des tests, le choix d'un pattern de conception s'impose parfois naturellement qu'après une réalisation.

Il est connu qu'un logiciel commence à mourir le jour de sa livraison (lorsqu'il est terminé).

lorsque les besoins commencent à changer, le système commence à mourir, et sa survie est son challenge. (Kirk Knoernshild, in "JOUP").

Un logiciel flexible est un logiciel qui accepte les changements sans (ou avec très peu) de modifications de code.

Le pari s'avère d'autant plus difficile que le changement fait partie de la nature même des besoins.

Tout l'art est alors d'identifier les parties sujettes aux changements afin de les abstraire, limitant ainsi les associations entre classes. Malheureusement cette pratique augmente la complexité du système.

	Coût de la fléxibilité
	Ce qui est flexible est complexe Il toute fois préférable de limiter la compléxité. Il s'agit donc de concilier fléxibilité et simplicité de conception. La complexité peut être cachée par l'adoption d'un framework, mais le système devient alors dépendant de celui-ci.

La recherche de la qualité en programmation objet tient en quelques mots : Gestion des dépendances (dépendance entre classes, dépendances entre paquetages). L'objetif étant de limiter les dépendances entre parties impémentées, pour une meilleure reutilisation, maintenance et flexibilité.

Le code source ne nous permet pas de distinguer clairement les dépendances entre des classes. Les clauses import donne des indications, mais sont parfois abusives.

Comment représenter ces dépendances ? par un diagramme UML.

UML devenant ainsi un outil d'aide à la décision.

Un élément A est dépendant d'un élément B lorsque la définition de A inclus celle de B.

Il y a dépendance chaque fois qu'une relation existe entre des éléments.

UML définit quatre relations entre éléments : Association, Généralisation, Réalisation et Dépendance.

Figure 2. Association

Figure 3. Généralisation

Figure 4. Réalisation

Figure 5. Dépendance

Parmi les associations, on distingue les agrégations et compositions.

Figure 6. Agrégation

Figure 7. Exemple (extrait des specs. UML 1.4)

Le relations se classent en deux catégories : à long terme et à court terme.

Dans la pratique, il y a trois principales raisons d'utiliser l'héritage :

Les langages ne font pas toujours une distinction nette de ces concepts. En effet une classe est présentée comme un tout composé d'une interface (un type) et d'une implémentation.

Java et l'héritage

Java fait la différence entre l'héritage d'interface (implements) et l'héritage d'implémentation (extends). Une classe peut être vue comme un type (opérations publiques) et une implémentation (méthodes et attributs), dans ces conditions une classe peut se dispenser de référencer explicitement une interface. class Vehicule { interface IFVehicule { private String immatriculation; public String getImmatriculation(); ... <==> } public String getImmatriculation() { class Vehicule implements IFVehicule { return this.immatriculation; private String immatriculation; } ... ... public String getImmatriculation() { } return this.immatriculation; } } Un objet peut jouer plusieurs rôles (sa classe implémente plusieurs interfaces). Un même rôle peut être joué par des objets de classes différentes (qui implémente la même interface).

Les diagrammes UML ne sont pas figés à un niveau de détail, un même point de vue peut être représenté avec différents niveaux de granularité. On retient généralement 3 niveaux conceptuel, spécification et implémentation, (Cook, S. and Daniels, J. Designing Object Systems: object-oriented modeling with Syntropy, Prentice Hall International, Hemel Hempstead, UK, 1994.), mentionnés par Martin Fowler ici .

Certaines pratiques [Catalysis, XP] ajoutent à cet axe vertical (du plus haut - conceptuel - au plus bas - le code -), un axe horizontal précisant la portée (scope). Par exemple un diagramme montrant une collaboration d'objets, gagnerait à préciser le niveau (par exemple Spécification) et la portée (par exemple le sous-système que cette collaboration sert, ou le cas d'utilisation concerné).

Figure 8. Niveaux et impacts

Exemple

Figure 9. Trois perspectives

Exercice 1

Produire un diagramme de classe UML à partir des éléments ci-dessous.

class Point { 
  protected int x; 
  protected int y; 
  public int getX(){return this.x;} 
  public void setX(int nouv_x){
    if (this.x != nouv_x)
       this.x = nouv_x;
  } 
  public int getY(){return this.y;}
  public void setY(int nouv_y){
    if (this.y != nouv_y) 
      this.y = nouv_y;
  }
  public Point() { super(); } 
}
class Point3D extends Point { 
  protected int z; 
  public int getZ(){return this.z;} 
  public void setZ(int nouv_z) {
    if (this.z != nouv_z) 
      this.z = nouv_z;
  }
  public Point3D() {super();}
}

interface Colorable { 
  public int getCouleur(); 
  public void setCouleur(int couleur); 
} 

class Point3DCouleur extends Point3D implements Colorable { 
  protected int couleur; 
  public int getCouleur() {return this.couleur;} 
  public void setCouleur (int couleur) { this.couleur = couleur; } 
  public Point3DCouleur() {super();} 
}

Exercice 2

Concevoir un diagramme de classe fidèle à l'implémentation du modèle pull du design pattern Observateur [Gof] ci-dessous :

public interface Observer {
  public void update(Observable o); 
}
 
public class Observable {
  Collection observateurs; 
  public void notify() { 
    Iterator it = observateurs.iterator();
    while (it.hasNext()) {
        Observer obs = (Observer) it.next();
        obs.update(this);
    }
  }

public void addObserver(Observer o) { observateurs.add(o); }
  ... 
}
  
public class Bilan extends Observable {
    void setChange() { notify(); }
    ... 
} 
  
public class UIGraphe implements Observer { 
    public UIGraphe(Observable o) { o.addObserver(this); } 
    public void update(Observable o) { 
       Bilan unbilan = (Bilan) o; 
       double compteResultat = unbilan.getCompteResultat();
       ... 
    } 
    ... 
}

En conception (design), il n'existe pas de règles strictes à appliquer, à l'image des formes normales en analyse de données (quitte à les enfreindre ensuite), mais des principes guidant la conception.

Pourquoi parler de guides et non de règles ?

Il n'est pas conseiller de vouloir toujours "faire du générique tout de suite", au risque de consommer du temps inutilement.

YAGNI veut dire "You aren't gonna need it" (Vous n'allez pas avoir besoin de lui). C'est un principe de précaution fondamental d'Extreme Programming, qui invite à la simplicité, mais pas n'importe laquelle... Si le sujet vous intéresse, l'ouvrage de Kent Beck est reconnu comme une excellente introduction en la matière (Références).

Il existe une relation étroite entre ces trois principes. DIP, associé à LSP, nous explique comment adhérer à OCP. En effet, les parties fermées (OCP) doivent s'appuyer sur des interfaces (IoC Principle) clairement exprimées et correctement réalisées (LSP).

Figure 18. Les trois grands principes

Voici un programme qui construit une page HTML représentant les caractères affichables de la table ASCII (code 32 à 127), accompagnés de leur valeur ordinale exprimée en base dix ou deux, selon l'argument fourni par l'utilisateur.

class TableAsciiToHTML {
  private char typeRepr;


  public TableAsciiToHTML(String typeRepr) {
    this.typeRepr= (typeRepr == null) ? 'd' : typeRepr.charAt(0);
    printHTML();
  }

  private void printHTML() {
    int deb = 32;
    int fin = 128;
    int nbCol = 10;
    int cpt = 0;
    System.out.println("<html><head /><body><center><h1>TABLE DE CARACTERES</h1>");
    System.out.println("<table border="1">");
    for (int i = deb; i < fin; i++, cpt++) {
      if (cpt%nbCol == 0) {
         if (i>deb)  System.out.println("</tr>");
         System.out.println("<tr>");
      }
      System.out.println("<td align=\"center\">");
      System.out.println("<table border=\"1\"> <tr>");
      System.out.println("<td bgcolor=\"teal\" align=\"center\">");
      switch (this.typeRepr) {
       case 'd' :
         System.out.println(toDecString(i));
         break;
       case 'b' :
         System.out.println(toBinString(i));
         break;
       default :
         System.out.println(toDecString(i));
      }
      System.out.println("</td></tr><tr>");
      System.out.println("<td bgcolor=\"#CC3300\" align=\"center\">");
      System.out.println(" &#" + i + "; </td></tr></table></td>");
    }
    System.out.println("</tr></table></center></body></html>");
  }

  private String toDecString(int n) {
     return String.valueOf(n);
  }

  private String toBinString(int n) {
     return Integer.toBinaryString(n);
  }

}

public class AppTableAscii {
  static void main(String[] args) {
     String arg = (args.length>0) ? args[0] : null;
     TableAsciiToHTML app = new TableAsciiToHTML(arg);
  }
}

Recopier ce programme puis compiler le.

javac AppTableAscii.java

Exécuter le en redirigeant la sortie standard vers une fichier portant l'extension .html.

java AppTableAscii > ascii.html

Visualiser le résultat avec un navigateur.

Recommencer en passant une valeur ('b') en ligne de commande

java AppTableAscii b > ascii.html

Visualiser le résultat avec un navigateur.

Bon, ok, le programme fonctionne. Toute fois il n'est pas très propre, les parties extensibles ne sont pas abstraites.

On souhaiterait proposer de nouvelles représentations des entiers sans avoir à retoucher l'existant (une fois retouché bien entendu).

On vous demande d'appliquer OCP (et DIP) sur cet existant. La refonte de l'application ne doit pas entrainer de changement visible de son comportement, les fonctionnalités restent identiques et l'utilisateur n'y voit que du feu... Remarque : La refonte d'une partie du code d'une application, sans impact sur ses fonctionnalités est appelée Refactoring, une activité quotidienne du développeur reconnue par eXtreme Programming.

Idée : Réaliser un couplage abstrait entre la logique de l'application (contruction d'une page HTML) et la représentation des nombres.

Objectif et test : Une fois l'application reconstruite, introduire une nouvelle représentation des valeurs ordinales en base 16, et ce sans intervenir sur le code existant de l'application.

Coad et Mayfield [Java Design] préconisent la stratégie suivante :

interface Representation {
  String toString(int i);
}

class Decimal implements Representation {
  public String toString(int i) {  
      return String.valueOf(i);
  }
}

class Binaire implements Representation {
  public String toString(int i) {  
     return Integer.toBinaryString(i);
  }
}

class TableAsciiToHTML {
  private Representation repr;

  public TableAsciiToHTML(Representation repr) {
      this.repr = repr;
      printHTML();
  }
 
  private void printHTML() {
    int deb = 32;
    int fin = 128;
    int nbCol = 10;
    int cpt = 0;
    System.out.println("<html><head /><body><center><h1>TABLE DE CARACTERES<h1>");
    System.out.println("<table border=\"1\">");
    System.out.println("<tr>");
    for (int i = deb; i < fin; i++, cpt++) {
      if (cpt%nbCol == 0) {
         if (i>deb)  System.out.println("</tr>");
         System.out.println("<tr>");
      }
      System.out.println("<td align=\"center\"");
      System.out.println("<table border=\"1\"> <tr>");
      System.out.println("<td bgcolor=\"teal\" align=\"center\">");
      
      System.out.println(repr.toString(i));

      System.out.println("</td></tr><tr>");
      System.out.println("<td bgcolor=\"#CC3300\" align=\"center\">");
      System.out.println(" &#" + i + "; </td></tr></table></td>");
    }
    System.out.println("</table></center></body></html>");
  }
  
}

class AppTableAscii {
  public static void main(String[] args) {
     String arg = (args.length>0) ? args[0] : "Decimal";
     try {
         Class c = Class.forName(arg);
         Representation repr = (Representation) c.newInstance();
         TableAsciiToHTML app = new TableAsciiToHTML(repr);
     }
     catch (ClassNotFoundException e) {
       System.out.println("Erreur : " + arg + " n'est pas une classe implémentée.");
     }
     catch (InstantiationException e) {
       System.out.println("Erreur : " + arg + " n'est pas n'est pas du type attendu.");
     }
     catch (IllegalAccessException e) {
       System.out.println("Erreur : " + arg + " n'est pas accessible.");
     }
  }
}
      
      

Nous allons maintenant tester la qualité Ouvert-Fermé, due au respect d'OCP (POF Principe d'Ouverture/Fermeture).

Créons une nouvelle classe d'implémentation de Representation.

public class Hexadecimal implements Representation {
  public String toString(int n) {
    return Integer.toHexString(n);
  }
}
  

Après compilation, nous exécutons le programme en lui passant en argument le nom de cette nouvelle classe.

  java AppTableAscii Hexadecimal > res.html

Le tour est joué.

Nous venons d'étendre le comportement de l'application sans intervenir sur son code.

Nous avons pour cela respecté OCP (POF) et appliqué DIP (PID).

Fichier de configuration XML

Notez que la fonction d'instanciation "paramétrée" est très souvent déléguée à une classe spécialisée (factory). Celle-ci puise très souvent les informations dont elle a besoin dans un (ou plusieurs) fichiers de configuration XML. Exemple (extrait d'un fichier de configuration d'une application Struts): <form-beans> <form-bean name="addQuestionForm" type="org.reseaucerta.qcm.presentation.AddQuestionForm"/> ... </form-beans> <!-- Action Mapping Definitions --> <action-mappings> <action path="/addQuestion" type="org.reseaucerta.qcm.application.AddQuestionAction" name="addQuestionForm" scope="session" validate="true" input="/jsp/addQuestion.jsp"> <forward name="success" path="/jsp/confirmAddQuestion.jsp"/> <forward name="echec" path="/jsp/echecAddQuestion.jsp"/> </action> ... <action-mappings>

Il existe une relation étroite entre les design patterns (modèles de conception) et les principes de conception objet.

Qu'est-ce qu'un design pattern ?

Un design pattern est une description d'une solution logicielle réutilisable face à un problème récurrent en développement informatique. (Mark Grand in Patterns in Java vol. 1).

L'origine : les modèles de construction architecturale par Christopher Alexander [1977].

Patterns logiciels : Kent Beck [1980] et Ward Cunningham [1987 et 1994].

Typologie des Patterns

Nous nous interessons aux patterns de conception (design patterns).

Ouvrage de référence :

Les design patterns offrent de nombreux avantages :

Les design patterns sont rangés dans des catalogues selon deux critères : le rôle (créateur, structurel, comportemantal) et le domaine (classe -statique- et objet -dynamique-) [Gof].

Figure 22. Catalogue GOF

D'autres catalogues sont proposés, notamment GRASP (General Responsability Assignement Software Patterns), ou patterns généraux d'affectation des responsabilités. Ces patterns décrivent quelques principes fondamentaux en conception objet (Expert, Créateur, Faible couplage, Forte cohésion, Contrôleur).

Principe directement concerné : DIP

La mise en oeuvre du couplage abstrait, que préconise DIP, nécessite toute fois un mécanisme d'instanciation afin de lier concrètement les classes, à un moment donné. C'est le rôle des patterns créateurs, en particulier ceux de type Factory.

Figure 23. Pattern Factory

Les solutions les plus connues sont méthode de fabrique (method factory) et fabrique abstraite (abstract factory).

La méthode de fabrique se charge de construire une instance, par exemple en fonction d'un discriminant reçu en argument.

La fabrique abstraite utilise l'héritage (et le polymorphisme) comme discriminant. Un système très souple qui permet à un client de choisir son fournisseur de classes concrètes.

Exemple 1

class RepresentationFactory {
  static Representation getInstance(char typeRepr) {
     Representation repr;
     switch (typeRepr) {
          case 'd' :
             repr = new Decimal();
             break;
          case 'b' :
             repr = new Binaire();
             break;
           default :
             repr = new Decimal();
     }
     return repr;
  }  
}

Exemple 2

interface RepresentationFactory {
  public Representation getInstance();
}

class ReprBinaire implements RepresentationFactory {
  public Representation getInstance(){
     return new Binaire();
  }   
}

class ReprDec implements RepresentationFactory {
  public Representation getInstance(){
     return new Decimal();
  }   
}

Sujet d'après un exemple présenté par Tony Sintes sur JavaWorld.com (2002).

Considérons le besoin suivant : On souhaite offrir aux programmes écrits en java la possibilité de « tracer » des mesages de debogage et d'erreur soit dans un fichier soit sur la console, et ceci de manière transparente.

Listing 1

 public interface Trace {

       // placer le debogage à on ou off
       public void setDebug( boolean debug );

       // ecrire un message de debug
       public void debug( String message );

       // ecrire un message d'erreur
       public void error( String message );

 }

Supposons que nous ayons écrit deux implementations. Une implémentation (Listing 2) écrit les messages sur la console, tandis que l'autre (Listing 3) les écrit dans un fichier.

Listing 2

 public class FileTrace implements Trace {
           
       private java.io.PrintWriter pw;
       private boolean debug;

       public FileTrace() throws java.io.IOException {
             // dans une version réelle, FileTrace aurait besoin
             // d'obtenir d'une manière ou d'une autre le nom du fichier
             // pour cet exemple, il sera codé en dur 
             pw = new java.io.PrintWriter( new java.io.FileWriter( "c:\trace.log" ) );
       }

       public void setDebug( boolean debug ) {
             this.debug = debug;
       }

       public void debug( String message ) {
             if( debug ) {  // imprimer seulement si debug est true
                   pw.println( "DEBUG: " + message );
                   pw.flush();
             }
       }
       public void error( String message ) {
             // toujours imprimer les erreurs
             pw.println( "ERREUR: " + message );
             pw.flush();
       }
 }

Listing 3

 public class SystemTrace implements Trace {

       private boolean debug;

       public void setDebug( boolean debug ) {
           this.debug = debug;
       }

       public void debug( String message ) {
           if( debug ) {  // imprimer uniquement si debug est true
                 System.out.println( "DEBUG: " + message );
           }
       }
       public void error( String message ) {
           System.out.println( "ERREUR: " + message );
       }
 }

Pour utiliser une de ces classes, nous nous y prendions comme cela :

Listing 4

 class Test {
   public void run() {
     int x = 2;
     SystemTrace log = new SystemTrace();
     log.debug( "debut du log" );
     try {
       int x = 1/(x-2);
     }
     catch (Exception e) {
        log.error(e.getMessage());  
     }
     log.debug("Valeur de x : " + x);
   }  
   ...
 }
 

On souhaite pouvoir changer de politique de trace (console, fichier ou autres) sans toucher au code des applications utilisant les services de trace.

Proposez une solution.

Nous devons découpler les programmes utilisateurs des fonctions de trace et les classes implémentant les services de Trace.

Nous respectons ainsi le principe ennoncé dans [Gof] : Programmer pour une interface et non pour une implémentation.

Remarque : Dans la version française de [Gof], le mot « développement » a été préféré (?) à « implementation ».

Dans la version proposée par l'auteur, les programmes clients délèguent entièrement le choix de la classe d'implémentation de Trace à une Factory.

 //... some code ...
 Trace log = traceFactory.getTrace();
 //... code ...
 log.debug( "entering loog" );
 // ... etc ...

Bien entendu, afin de gagner en souplesse, la factory devra initialement être obtenu au moyen du design pattern Abstract Factory :

interface TraceFactory {
   public  Trace getTrace();
}

Version initiale : les traces sont réalisées sur la console.

 public class TraceConsoleFactory implements TraceFactory {
       public Trace getTrace() {
             return new SystemTrace();
       }
 }

Variante (sans intervenir sur les programmes client) : les traces sont réalisées dans un fichier, toute fois, si cela s'avère impossible, les traces se feront sur la console.

 public class TraceFileFactory implements TraceFactory {
    public Trace getTrace() {
      try {
         return new FileTrace();
      } catch ( java.io.IOException ex ) {
         Trace t = new SystemTrace();
         t.error( "could not instantiate FileTrace: " + ex.getMessage() );
         return t;
      }
   }
 }

Dès lors nous pouvons imaginer une classe :

 public class AbstracTraceFactory {

    public static TraceFactory getTraceFactory()
    throws CreateTraceFactoryException {   
      try {
         // recherche dans un fichier de configuration
         // la factory à instancier 
         // ...
         // par exemple :
         return new FileTraceFactory();
         
      } catch ( Exception ex ) {
         throw new CreateTraceFactoryException(ex);
      }

   }

 }