class Person
{
private BankAccount account;
Person(BankAccount account)
{
this.account = account;
}
public Person someMethod(Person person)
{
//Why accessing private field is possible?
BankAccount a = person.account;
}
}
Veuillez oublier le design. Je sais que la POO spécifie que les objets privés sont privés pour la classe. Ma question est la suivante: pourquoi la POO a-t-elle été conçue de telle sorte que les champs privés aient un accès au niveau de la classe et non un accès au niveau de l'objet ?
someMethod
n'est pas valide. Cela ne renvoie rien. Ça doit êtrevoid
.Réponses:
Je suis également un peu curieux de connaître la réponse.
La réponse la plus satisfaisante que je trouve vient d'Artemix dans un autre article ici (je renomme l'AClass avec la classe Person): Pourquoi avoir des modificateurs d'accès au niveau de la classe au lieu du niveau de l'objet?
EDIT: Veuillez voter pour la réponse d'Artemix. Je fais juste un copier-coller.
la source
Person
, dans la classePerson
, n'a pas besoin de connaître l'implémentation de la classe entière. La bonne pratique consiste à utiliser l'accesseur, sans avoir à connaître les opérations effectuées par l'accesseur.equals(Object)
méthode dans une classe Java pour vérifier l'égalité d'unPerson
objet avec une autre instance dePerson
. Vous souhaiterez peut-être permettre au monde extérieur de vérifier si les deux instances sont égales, mais vous ne souhaiterez peut-être pas exposer tous les champs privés de la classe nécessaires pour vérifier l'égalité avec le monde extérieur à l'aide des méthodes d'accès public. Avoir un accès de niveau classe auxprivate
champs permet d'implémenter une telle méthode sans la nécessité induite d'implémenter de telles méthodes publiques.equals
).equals
peut être effectuée en appelant des accesseurs privés.private
accorder un accès au niveau de la classe. Je conviens que l'utilisation des accesseurs est généralement une bonne habitude, même si dans ce cas, c'est surtout une question de contexte et de style personnel. Notez que Joshua Bloch dans Effective Java (point 8) et Tal Cohen dans cet article de Dr. Dobbs accèdent directement aux champs privés dans leurs listes de codes lorsqu'ils discutent de la mise en œuvreequals
.Voir la spécification du langage Java, section 6.6.1. Déterminer l'accessibilité
Il est dit
Cliquez sur le lien ci-dessus pour plus de détails. Donc, la réponse est: parce que James Gosling et les autres auteurs de Java ont décidé qu'il en était ainsi.
la source
Bonne question. Il semble que le modificateur d'accès au niveau de l'objet appliquerait encore plus le principe d'encapsulation.
Mais en fait, c'est l'inverse. Prenons un exemple. Supposons que vous souhaitiez copier en profondeur un objet dans un constructeur, si vous ne pouvez pas accéder aux membres privés de cet objet. Ensuite, le seul moyen possible est d'ajouter des accesseurs publics à tous les membres privés. Cela rendra vos objets nus à toutes les autres parties du système.
L'encapsulation ne signifie donc pas être fermé à tout le reste du monde. Cela signifie être sélectif à propos de qui vous voulez être ouvert.
la source
o.deepCopy()
ou autre.Cela fonctionne parce que vous êtes dans
class Person
- une classe est autorisée à pénétrer dans son propre type de classe. Cela aide vraiment lorsque vous souhaitez écrire un constructeur de copie, par exemple:Ou si nous voulons écrire
operator+
etoperator-
pour notre grande classe de nombres.la source
Juste mes 2 cents sur la question de savoir pourquoi la sémantique de la visibilité privée en Java est au niveau de la classe plutôt qu'au niveau de l'objet.
Je dirais que la commodité semble être la clé ici. En fait, une visibilité privée au niveau objet aurait obligé à exposer des méthodes à d'autres classes (par exemple dans le même package) dans le scénario illustré par l'OP.
En vérité, je n'ai pas été en mesure de concocter ni de trouver un exemple montrant que la visibilité au niveau de la classe privée (comme celle offerte par Java) crée des problèmes par rapport à la visibilité au niveau de l'objet privé.
Cela dit, les langages de programmation avec un système plus fin de politiques de visibilité peuvent offrir à la fois une visibilité des objets au niveau de l'objet et au niveau de la classe.
Par exemple Eiffel , propose une exportation sélective: vous pouvez exporter n'importe quelle caractéristique de classe vers n'importe quelle classe de votre choix, de {NONE} (object-private) à {ANY} (l'équivalent de public, et aussi la valeur par défaut), vers {PERSON} (class-private, voir l'exemple de l'OP), à des groupes spécifiques de classes {PERSON, BANK}.
Il est également intéressant de remarquer que dans Eiffel, vous n'avez pas besoin de rendre un attribut privé et d'écrire un getter pour empêcher d'autres classes de lui attribuer. Les attributs publics dans Eiffel sont par défaut accessibles en mode lecture seule, vous n'avez donc pas besoin d'un getter juste pour renvoyer leur valeur.
Bien sûr, vous avez toujours besoin d'un setter pour définir un attribut, mais vous pouvez le masquer en le définissant comme "assigner" pour cet attribut. Cela vous permet, si vous le souhaitez, d'utiliser l'opérateur d'affectation le plus pratique au lieu de l'invocation du setter.
la source
Parce que le
private
modificateur d'accès le rend visible uniquement dans la classe . Cette méthode est toujours dans la classe .la source
le
private
champ est accessible dans la classe / l'objet dans lequel le champ est déclaré. Il est privé pour les autres classes / objets en dehors de celui dans lequel il se trouve.la source
Avec le concept de réflexion en Java, il est possible de modifier les champs et les méthodes privés
Modificando metodos y campos privados con Refleccion en Java
la source
La première chose que nous devons comprendre ici est que tout ce que nous avons à faire est de suivre les principes oops donc l'encapsulation consiste à dire que les données enveloppent le package (c'est-à-dire la classe) et que toutes les données soient représentées sous forme d'objet et faciles d'accès. donc si nous rendons le champ non privé, il y accède individuellement. et il en résulte une mauvaise paratice.
la source