Discussion :

[naou18]

Bonjour tous le monde,

J'aimerai savoir c'est quoi la vrai utilité d'utilisé l'encapsulation OO (accès indirect )en java, au lieu d’accéder directement au variable d'instance.
Est ce que ça permet (encapsulation )tous d'abord la réutilisation, et le faite de changer la structure de donnée en cas de besoins.Si c'est oui, veuillez me donner un exemple concret.
Et bien sur s'il a d'autre avantage je suis preneur.

Merci d'avance pour votre aide.

[druzy]

L'encapsulation, sert à rendre impossible la modification d'une variable si l'auteur d'une classe ne veut pas que cela soit possible.

C'est très pratique pour les projets à plusieurs.

[zo1odMSQr5Fy]

Bonjour tous le monde,

J'aimerai savoir c'est quoi la vrai utilité d'utilisé l'encapsulation OO (accès indirect )en java, au lieu d’accéder directement au variable d'instance.
Est ce que ça permet (encapsulation )tous d'abord la réutilisation, et le faite de changer la structure de donnée en cas de besoins.Si c'est oui, veuillez me donner un exemple concret.
Et bien sur s'il a d'autre avantage je suis preneur.

Merci d'avance pour votre aide.

Regarde l'intérêt des mots clés : private, protected

L'encapsulation peut te permettre d'accéder en lecture à des données ( private) et à les modifier( public et protected selon certaines conditions )

[naou18]

Merci pour vos réponse,

@druzy:
l'encapsulation ne sert pas à rendre impossible la modification d'une variable, en fait tu peux le faire à l'aide d'un setter setAttribut(Type paramètre).

@TheBear: je connais l'utilité de ces mots clés:

Je veux savoir quelle est l'avantage concrètement d’utilisé l'encapsulation.

Merci.

[sinok]

S'assurer que les attributs d'une classe seront modifiées de la façon attendue, et uniquement de cette façon.
En effet dans la méthode set tu peux appliquer de contrôles, des calculs, générer des évènements et ainsi de suite à chaque appel. Alors qu'en laissant l'accès direct à ta variable, tu ne peux avoir aucune idée de ce qui va être fait. De fait c'est une dès règles de bases en design d'API objet.

[naou18]

Merci pour vos réponse:

@sinok: c'est tout à fait ce que je recherche .
Est ce que je peux avoir un exemple concret auquel on applique des contrôles ou calcule à la méthode set.

[wax78]

Tu pourrais faire par exemple quelque chose du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
Class formeRect{
double x,y,w,h;
double poidsenNewton;
 
double setPoidsEnKilo(double poidsenKilo) throw new Exception
{
if  (poidsenKilo>5000) throw Exception("Poids trop elevé");
poidsenNewton=poidsenKilo/9.81;
 
}
 
}

(bon c'est un exemple idiot je sais ...)

En gros tu passes un variable a une methode set, et dedans tu regarde une condition et tu envoye une exception (dans ce cas ci) pour avertir.

[tchize_]

Ca sert aussi quand tu sous classe. Impossible de modifier le comportement d'un champ, par contre il est possible de modifier le comportement d'un getter / setter.

Par exemple, quelle que soit la classe de base concernée. Si tu n'a pas protégé les champs, impossible de lui appliquer par la suite la pattern "wrapper". Et par expérience, je peux te dire que dans 99.9% des cas ou t'as besoin d'appliquer la pattern wrapper, tu n'en avais aucunement l'intention quand tu a démarré la classe de base. Bref, c'est aussi une question de politesse par rapport aux utilisateurs de ta classe Ca permet de leur laisser le champ libre, ce que tu ne peux pas faire avec des champs publics.

[professeur shadoko]

exemple stupide (mais a but pédagogique)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
public class UneDate { //version 1
    private int jour;
    private int mois ;
    private int annéé ;
   public UneDate(int jour, int mois, int année) {
      // controles et initialisations
   }
 
  public int getJour()  { /*ce qu'il faut */ }
  public int getMois()  ..... /etc.
}

bon on change d'avis au niveau de l'implantation ...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
public class UneDate { //version 2
    private long time ;
   public UneDate(int jour, int mois, int année) {
      // controles et initialisations
   }
 
  public int getJour()  { /*ce qu'il faut */ }
  public int getMois()  ..... /etc.
}

ceux qui utilisent ce code ont-ils besoin de modifier leur code si tu changes d'avis avec la version 2? réponse non!
tu changes ton code mais pas le contrat qui te lie à ceux qui l'utilisent!

[kolodz]

C'est aussi le principe de l'interface :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
interface IDate { 
     public int getJour();
     public int getMois();
}

Une interface n'a par définition pas de champs private.
Il est toujours utile d'avoir des getter/setter pour savoir ce qui se passe. Ou ajouter une fonction non prévu.
Besoin de déclencher un event quand on modifie/acces un objet ? (log/persistance/etc) Tu le place au niveau de ton set/get et on en parle plus.
Les get/set, on se rend compte de leur utilité quand on en a besoin et qu'ils ne sont pas là. Genre, 10/40/100 affectation de valeurs à retrouver et modifier dans le code ?

Sinon, j'approuve tchize_ et sinok. Même si il est possible de faire des contrôles sur le set d'une valeur avec de la programmation orienté aspect.(AspectJ)
Mais, ce n'est pas parce que c'est possible qu'il faut le faire.

[naou18]

Merci pour votre aide.

@Kodozo: je ne voix pas l’intérêt de ton exemple avec les interfaces, car ces derniers ne contient aucun attributs par définition, une interface contient les signature des méthodes.
Pardonne moi si j'ai pas compris ton propos.

[JoeChip]

A la base, c'est surtout pour découpler le code, ce qui veut dire que quand on modifie un truc on n'est pas obligé de modifier partout dans le code, et aussi qu'on peut facilement faire des classes qui héritent d'une classe donnée, sans devoir modifier le code ailleurs que dans la nouvelle classe.

Mettons que tu fais un jeu avec des objets qui ont un poids; tu as donc dans ta classe une propriété qui s'appelle "poids".

Si tu accède directement, depuis un autre objet ("panier"), à un moment tu fais "poidsPanier += monObjet.poids;", par exemple. Jusque là tout va bien. Mais admettons qu'ensuite tu définisse un objet dont le poids varie avec le temps. Du coup, tu as deux solutions : ou bien mettre ce poids à jour en permanence, pour qu'au moment où on l'utilise il soit correct, ou bien modifier le code dans la classe appellante pour qu'elle fasse un calcul sur le poids dans le cas où il faudrait.

La première solution est compliquée et gourmande en ressources, la deuxième est contraire à l'idée de POO, puisqu'on fait une distinction entre des objets qui sont apparentés, ce qui oblige à modifier du code à un endroit où ça ne devrait pas être nécessaire : pour connaître le poids du panier, en principe tu ne doit connaître des objets que leur poids, sans t'occuper de savoir de quel objet il s'agit exactement.

Alors que si dès le départ tu as écrit un getter, tu n'as plus qu'à le modifier dans donc nouvel objet pour qu'au lieu de faire "return poids;" il fasse un genre de "return poids*coeff/sqrt(new MachinsBizarre().getDiviseur());" et tu ne devras rien modifier ailleurs... Donc si après ya un bug, tu sais où il est...

[professeur shadoko]

C'est aussi le principe de l'interface :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
interface IDate { 
     public UneDate(int jour, int mois, int année);
     public int getJour();
     public int getMois();
}

le copier/coller est notre pire ennemi
(le constructeur dans une interface est une erreur de collage: c'est pas un reproche car ça m'arrive tout le temps .....)

[naou18]

Bonjour,

@ kolodz: je ne vois toujours pas l’intérêt d'une interface concernant l'encapsulation.

Merci.

[GPPro]

C'est aussi le principe de l'interface :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
interface IDate { 
     public UneDate(int jour, int mois, int année);
     public int getJour();
     public int getMois();
}

Juste deux remarques :

public est redondant avec la déclaration d'interface (dans une interface toutes les méthodes sont publiques).

Le nom IDate est juste moche : en général il est mieux d'appeler son interface par un nom clair et précis (ici, Date) et faire le marquage au niveau de l'implémentation (DateImpl par exemple). Tout simplement car l'utilisateur d'une API passera par l'interface. C'est purement cosmétique mais ça a son importance.

L'interface est une généralisation de l'encapsulation : on masque une implémentation pour pouvoir la modifier sans que cela impacte le code de l'utilisateur.

[kolodz]

Le nom IDate est juste moche : en général il est mieux d'appeler son interface par un nom clair et précis (ici, Date) et faire le marquage au niveau de l'implémentation (DateImpl par exemple). Tout simplement car l'utilisateur d'une API passera par l'interface. C'est purement cosmétique mais ça a son importance.

Pour le coup, c'est une convention de nommage. Afin de faire la différence entre une classe et une interface. Je ne l'ai pas inventé. Et crois-moi elle est utilisé pour de bonne raison.

public est redondant avec la déclaration d'interface (dans une interface toutes les méthodes sont publiques).

C'est une évidence, oui. Mais ça ne tue personne de le rappeler. C'est comme toujours indiquer public/private/protected sur les variables/fonctions/classes.
Je me souviens des valeurs par défauts, mais je ne sais pas qui relira mon code et avec quel niveau de compétence.

@ kolodz: je ne vois toujours pas l’intérêt d'une interface concernant l'encapsulation.

L'encapsulation permet la définition d'interface et un certains nombre de pattern de conception. Ce n'est que l'aboutissement de ce que dit "professeur shadoko".
Tu définis ce que tu veux (l'interface). Puis, tu fait une implémentation.

[Robin56]

Pour le coup, c'est une convention de nommage. Afin de faire la différence entre une classe et une interface. Je ne l'ai pas inventé. Et crois-moi elle est utilisé pour de bonne raison.

Je confirme.

C'est une évidence, oui. Mais ça ne tue personne de le rappeler. C'est comme toujours indiquer public/private/protected sur les variables/fonctions/classes.
Je me souviens des valeurs par défauts, mais je ne sais pas qui relira mon code et avec quel niveau de compétence.

Je confirme également.

PS : Ne me remerciez pas pour mon intervention.

[tchize_]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
interface IDate { 
     public UneDate(int jour, int mois, int année);

PAN!
Vous irez me laver cet écran au savon!

[GPPro]

Pour le coup, c'est une convention de nommage. Afin de faire la différence entre une classe et une interface. Je ne l'ai pas inventé. Et crois-moi elle est utilisé pour de bonne raison.

C'est une évidence, oui. Mais ça ne tue personne de le rappeler. C'est comme toujours indiquer public/private/protected sur les variables/fonctions/classes.
Je me souviens des valeurs par défauts, mais je ne sais pas qui relira mon code et avec quel niveau de compétence.


L'encapsulation permet la définition d'interface et un certains nombre de pattern de conception. Ce n'est que l'aboutissement de ce que dit "professeur shadoko".
Tu définis ce que tu veux (l'interface). Puis, tu fait une implémentation.

C'est beau les étudiants plein de certitudes et donneurs de leçons...

Une petite discussion sur le sujet : http://stackoverflow.com/questions/5...naming-in-java

[thelvin]

Autant je suis d'accord avec toi, GPPro, ainsi qu'avec la réponse la mieux notée à l'heure actuelle,

autant je ne citerais jamais stackoverflow comme une référence de quoi que ce soit.
Edit : snip le reste, j'avais mal lu.