Les "cercles" de responsabilité

images/whitebelt.png

private

A un moment donné le code d’une classe est sous la responsabilité d’un programmeur. Il doit savoir quel est le comportement attendu du code de la classe et il est responsable d’une réalisation correcte (des règles métier par exemple).

Les autres programmeurs ne doivent pas modifier son code ni en connaître les détails de réalisation. Ce qui est reservé à l’usage exclusif du programmeur responsable est marqué private.

Le modificateur private réduit la portée des membres et constructeurs de premier niveau: ces éléments ne seront accessibles que par le code courant (ceci dit le terme "modificateur d’accès" est ambigu : il ne s’agit pas de gérer des droits d’accès aux objets!).

public class Truc {
   private int z ;
   public void modifie(Truc autreInstance) {
      autreInstance.z = this.z ; // PARFAITEMENT LEGAL!!!
   }
}

Dans cet exemple le devenir du champ z est sous la responsabilité du programmeur qui a écrit la classe Truc. Il a donc parfaitement le droit de faire ce qu’il veut. (Encore une fois private n’est pas un système de défense bloquant l’accès aux données par des codes extérieurs à l’instance courante!). Un membre ou un constructeur private est accessible par tout code en portée.

public

Le programmeur responsable d’un code met des "prestations" à la disposition des autres programmeurs. La plupart du temps c’est juste un point d’accès marqué public: le code client connait la signature de la prestation mais ne connaît pas le code qui le réalise. On définit ainsi un contrat qui lie un fournisseur de prestations à ses utilisateurs (les codes "client").

[Avertissement]Attention

images/bluebelt.png

Une fois qu’un code est publié (c’est à dire à partir du moment où des programmeurs d’une autre organisation que celle qui a créé le code ont investi dans l'écriture de codes qui utilisent le code "publié") on ne peut plus changer l’A.P.I. d’un code d’une manière qui rendrait invalides des codes client.

Dans des versions ultérieures on pourra:

  • enrichir une A.P.I (ajouter des membres ou des constructeurs).
  • rendre obsolete des éléments de l’A.P.I. en les marquant par l’annotation @Deprecated : quand un code client est recompilé avec cette nouvelle version de la classe le compilateur émettra un warning.

un exemple d’une méthode obsolete dans l’A.P.I standard Java

[Avertissement]

images/whitebelt.png

Une "légende urbaine" tenace sur java prétend que pour chaque classe il faut disposer d’un constructeur sans paramètres et que pour chaque champ il faut une paire accesseur/mutateur: LIRE ICI: la malheureuse histoire des beans

Quelques exercices à ce niveau :

contrôles de syntaxe

écriture de code

design

"friendly"

images/whitebelt.png

Il y a un niveau intermédiaire entre les codes sous la responsabilité exclusive de leur créateur et les codes "client" au sens large. Une classe peut exister dans un cercle restreint de classes qui concourent à un but commun.

Un tel groupe s’appelle un package. Le programmeur responsable d’une classe est censé travailler au sein d’une équipe et cette équipe est en charge d’un package.

Les membres et constructeurs qui n’ont aucun modificateurs d’accès (comme public ou private) sont implicitement package friendly. C’est à dire qu’ils sont en portée pour les codes des classes du même package.

Remarquons qu’un programmeur est censé coopérer avec les autres programmeurs de son équipe. Dans ce cas il est possible de modifier la signature d’un élément qui est package friendly (vos collègues devront être avertis des modifications du code de référence et agir en conséquence!).

   // code écrit pour l'usage exclusif des autres membres de l'équipe!
   static double échéancier(double montantPrêt, int durée, double taux) {
      // code
   }
   // OOPS! pardon : en version 2 la méthode renvoie un double[] !