Encapsulation vs. Accès direct

Version imprimable

29/11/2011, 13h21
naou18

Encapsulation vs. Accès direct

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.
29/11/2011, 14h01
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.
29/11/2011, 14h34
zo1odMSQr5Fy

Citation:

Envoyé par 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.

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 )
29/11/2011, 14h55
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.
29/11/2011, 15h17
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.
29/11/2011, 15h34
naou18

Merci pour vos réponse:

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

Tu pourrais faire par exemple quelque chose du genre :
Code:

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.

29/11/2011, 16h51
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.

exemple stupide (mais a but pédagogique)

Code:

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:

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!

30/11/2011, 00h09
kolodz
C'est aussi le principe de l'interface :
Code:

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.
30/11/2011, 01h22
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.
30/11/2011, 09h33
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...
30/11/2011, 13h17
professeur shadoko
Citation:
Envoyé par kolodz

C'est aussi le principe de l'interface :

Code:

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 :aie:
(le constructeur dans une interface est une erreur de collage: c'est pas un reproche car ça m'arrive tout le temps .....:oops:)
30/11/2011, 13h30
naou18

Bonjour,

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

Merci.
30/11/2011, 15h17
GPPro
Citation:
Envoyé par kolodz

C'est aussi le principe de l'interface :

Code:

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.
30/11/2011, 17h12
kolodz

Citation:

Envoyé par GPPro

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.

Citation:

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.

Citation:

@ 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.
30/11/2011, 18h04
Robin56

Citation:

Envoyé par kolodz

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.

Citation:

Envoyé par kolodz

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.
30/11/2011, 18h54
tchize_
Citation:
Envoyé par kolodz

Code:

1 2 interface IDate { public UneDate(int jour, int mois, int année);
PAN! :aie:
Vous irez me laver cet écran au savon!
01/12/2011, 10h36
GPPro

Citation:

Envoyé par kolodz

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
01/12/2011, 11h57
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.
01/12/2011, 12h04
JoeChip

Il y a un comm qui dit ça :

Citation:

Code using an instance of some type should never, ever care if that type is an interface or a class or what.

Amha, c'est le fond de l'histoire... Donc ça donne "Date" comme nom de l'interface, en fait... Ou de la classe dont l'utilisateur manipule une instance.
01/12/2011, 12h13
GPPro

Citation:

Envoyé par 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.

Et bien tu as tort... Stackoverflow est une des meilleures ref aujourd'hui. Après c'est comme tous les sites, tu fais le tri, mais il n'empêche qu'il y a énormément de gens compétents qui postent sur SO.
01/12/2011, 12h15
GPPro

Citation:

Envoyé par BenWillard

Il y a un comm qui dit ça :

Amha, c'est le fond de l'histoire... Donc ça donne "Date" comme nom de l'interface, en fait... Ou de la classe dont l'utilisateur manipule une instance.

Oui, peut-être qu'on peut voir les Itruc comme un vieux reste de la notation polonaise chère aux programmeurs windows oldschool.
01/12/2011, 12h19
naou18

Bonjour,

Si vous voulez continue à débattre je suis d'accord, mais n'oublie pas le contexte c'est encapsulation vs Accès direct.
pour les convention de nommage ou les "best practice" chacun c'est argument.
s'il y a un plus par rapport au contexte je suis preneur.

Merci
01/12/2011, 15h25
tchize_

Il n'y a pas de raison d'avoir des conventions de nommage séparée pour les interfaces, puisqu'elles s'utilisent de la même manière que les classes. D'ailleurs, l'api java ne fait pas de distinction.

Pour revenir au sujet, le nommage des tes accesseurs font aussi partie de conventions de nommage: getXxx, setXxx, isXxx où Xxx contient un ou plusieurs mot en uppercamel case mais pas de verbe (le verbe ici étant seulement to get, to set et is).