Voilà désolé de reposer la question mais j'ai lu les autres posts sur le sujet mais je ne comprend toujours pas l'utilité de l'encapsulation.
L'encapsulation servirai a protéger le contenue de mes variables dans ma Classe et éviter que quelqu'un viennent utiliser mes variables.
Mais que je fasse un
ville.nomPays="France";
ou un
Ville ville = new ville ("France);
dans les deux cas je peux modifier la variable et mettre ce que je veux
dedans donc ou est l'intérêt ?
Je suis débutant et il y a certains concepts que j'ai beaucoup de mal a assimiler donc si vous pouviez me parler comme à un enfant de 5 ans ça serai pas de refus
Ici "France" est une valeur d'entrée. A ne pas confondre avec l'état interne que sont les attributs.
En POO l'encapsulation vise à exposer aux utilisateurs des fonctionnalités (méthodes), et de cacher le fonctionnement interne (attributs). La mise en pratique de l'encapsulation est simple : attributs privés, et (si besoin) des getter/setter. En théorie les getter et surtout les setter cassent l'encapsulation. On préférera donc le passage au constructeur si la valeur est constante ou qu'il n'y a pas besoin d'appel au setter.
C'est une notion simple à comprendre techniquement, mais compliquée à mettre proprement en pratique car il faut que ton programme soit bien conçu (sinon tu te retrouveras obligé d'utiliser des setters). Avec l'expérience et donc le recul, tu comprendras mieux.
Angular 2 est l'avenir, jQuery c'est de la merde !!! - Java 8 c'est l'an 2016+ (programmez en 1 ligne)
En théorie les getter et surtout les setter cassent l'encapsulation.
@czar1983 : Pour rebondir là dessus, pour penser en objet, la première chose à laquelle tu dois réfléchir quand tu penses à une classe est "comment je vais l'utiliser" et surtout pas "qu'est ce que je vais mettre dedans". En pensant de la première manière, comme tu ne décides pas encore de ce que contient ta classe, tu es bien moins tenté de faire des gets et des sets dessus.
Tu peux également t'intéresser aux différents principes SOLID.
>L'encapsulation servirai a protéger le contenue de mes variables dans ma Classe et éviter que quelqu'un viennent utiliser mes variables.
Petite remarque:
L'encapsulation n'est pas un outil dédié à la sécurité contre l'espionnage ou autre. Il protège simplement des erreurs d'inattentions, ça n'empêche personne d'accéder aux données de tes objets/classes. (cf. la réflexion/introspection)
Ici "France" est une valeur d'entrée. A ne pas confondre avec l'état interne que sont les attributs.
ça par contre pas du tout, pourquoi utiliser des get set dans le cours alors si le but d'un attribut privée est d'être caché pour mêler les deux sachant que l'attribut privé perd de son sens ?
En POO l'encapsulation vise à exposer aux utilisateurs des fonctionnalités (méthodes), et de cacher le fonctionnement interne (attributs).
Qu'est ce que le passage au constructeur? La mise en pratique de l'encapsulation est simple : attributs privés, et (si besoin) des getter/setter. En théorie les getter et surtout les setter cassent l'encapsulation.
La c'est du charabia pour moi , un petit exemple ?
On préférera donc le passage au constructeur si la valeur est constante ou qu'il n'y a pas besoin d'appel au setter.
SongBird_ a écrit:
Salut,
L'encapsulation servirai a protéger le contenue de mes variables dans ma Classe et éviter que quelqu'un viennent utiliser mes variables.
Petite remarque:
L'encapsulation n'est pas un outil dédié à la sécurité contre l'espionnage ou autre. Il protège simplement des erreurs d'inattentions, ça n'empêche personne d'accéder aux données de tes objets/classes. (cf. la réflexion/introspection)
Est ce que par erreur inattention tu veux dire le fait de ne pas respecter le type de variable ou l'ordre du constructeur de mon objet quand j’initialise un nouvel objet ?
ça par contre pas du tout, pourquoi utiliser des get set dans le cours alors si le but d'un attribut privée est d'être caché pour mêler les deux sachant que l'attribut privé perd de son sens ?
Aucun. Cet exemple est très mal choisi en fait puisqu'un objet "Ville" n'a approximativement aucune utilité. Cela fait partie du sens de ma remarque. En objet, on pense en terme de service. "A quoi sert mon objet ?". Ici, on ne peut pas en faire grand chose ... Une ville sert à ... stocker les données d'une ville ? Aucun intérêt.
czar1983 a écrit:
Qu'est ce que le passage au constructeur?
Ton constructeur peut recevoir des paramètres. Si on reprend l'exemple, certes mauvais, de la ville. Une ville ça ne change pas de nom. Donc il n'y a pas d'intérêt à faire un setter sur son nom. On lui donne donc la chaîne qui correspond à son nom en paramètre de constructeur.
czar1983 a écrit:
Est ce que par erreur inattention tu veux dire le fait de ne pas respecter le type de variable ou l'ordre du constructeur de mon objet quand j’initialise un nouvel objet ?
Si la visibilité des attributs de ton objet est "public", tu ne peux plus garantir que les bonnes propriétés qu'il peut avoir son assurées parce que l'utilisateur peut aller tripatouiller comme il veut les données internes avec ses mains sales. L'encapsulation permet d'empêcher cela. Par exemple, tu peux imaginer une classe Fraction qui sert à faire des opérations sur les fractions. En interne, on lui donnera un état qui contiendra le numérateur et le dénominateur.
Pour avoir une représentation compacte et éviter les dépassements au fil des calculs, il est commode de toujours garder une fraction irréductible. Par exemple, si on a :
Fraction f1 = new Fraction(1,6);
Fraction f2 = new Fraction(1,6);
Fraction f3 = f1.add(f2);
Si on calcule bêtement f3, on aura dedans 2/6, qui se simplifie très bien en 1/3. Et donc ce qu'on va vouloir faire, c'est avoir un invariant sur notre classe qui nous dira qu'en interne, la fraction est toujours irréductible. Donc ce qu'on fera c'est qu'après chaque instruction de calcul, on calculera la fraction irréductible.
Maintenant, si on a plus d'encapsulation, on ne peut plus garantir ça. Parce que l'utilisateur (programmeur) de la classe pourrait dire :
f3.denominateur = 42;
Et comme il ne fait pas le calcul de la fraction irréductible, on perd notre propriété invariante à propos des fractions.
>Est ce que par erreur inattention tu veux dire le fait de ne pas respecter le type de variable ou l'ordre du constructeur de mon objet quand j’initialise un nouvel objet ?
EDIT: Ksass`Peuk vient de griller mon post, tout est dit.
Non, pas vraiment.
Admettons que tes attributs ne sont absolument pas encapsulés, soit une classe C:
public class C {
public CustomObject co;
public C(final CustomObject co)
{
/* ton objet perso doit respecter certains critères
pour être assigné à l'attribut de la classe...
*/
}
public static void main(String[] args)
{
CustomObject good_co = new CustomObject(a, b, c); // cet objet va respecter les conditions imposés.
CustomObject bad_co = new CustomObject(w, x, y);
C c = new C(good_co);
/*
...
*/
c.co = bad_co;
/*
L'exemple est un peu tordu, mais on se retrouve avec un objet
non-testé et donc potentiellement bugué.
L'attribut étant muable, on peut lui injecter une nouvelle référence
qui n'aura pas été testée par le constructeur avant la création de l'objet.
Si tu souhaites rendre un attribut publique, assure-toi qu'il sera filtré par le constructeur
et immuable.
*/
}
}
Super j'ai pas tout compris notamment la partie Fraction mais je vois pourquoi maintenant les set et les get ne me servent à rien, si ma classe ne fournis pas un service.
Donc je continue à utiliser les set et les get si ma class fournis un service ? car j'ai cru comprendre que il ne fallait pas utiliser les set et les get avec des éléments privée .
Ta classe doit toujours fournir une service à moins que tu fasses de l'orienté données. Si tu as bien pensé ton service, il y a peu de chances que tu aies des getters/setters. Cela dit, il n'est pas si rare d'avoir des getters pour recevoir des valeurs, cela peut faire partie d'un service. Exemple concret : on a bien envie de connaître la taille d'une liste.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C