7
votes

Modificateurs d'accès OOP: Compilation-Time ou Temps d'exécution

J'ai entendu dire que modificateurs d'accès public, privé et protégé ne sont que des trucs de compilateur et ils n'existent pas dans le code binaire compilé .

Maintenant, je me demande combien il est correct? Et si c'est correct, cela signifie-t-il que encapsulation n'existe pas dans le code binaire au moment de l'exécution? Donc, si vous modifiez le binaire pour accéder à une méthode illégalement, en théorie, il n'y a rien à vérifier vos droits, ni aucun mécanisme d'oopisme ni système d'exploitation, non?

J'ai aussi étiqueté la question pour C ++ et Java. Je suis au courant de la différence entre eux, juste curieux de voir à quel point ils manipulent modificateurs d'accès .


0 commentaires

3 Réponses :


2
votes

Veuillez noter que cette réponse concerne Java
Les deux. Si vous essayez de compiler le code qui essaie d'accéder à un objet ou à une méthode inaccessible, vous obtiendrez une erreur de compilation:

et au moment de l'exécution, JVM vérifie l'accès:

Vous recevrez une exception suivante si vous essayez d'accéder au temps d'exécution. Avec un niveau d'accès incorrect Java.lang.illegalAccessError:

espère qu'il aide


1 commentaires

Merci, c'est pourquoi j'ai marqué les deux C ++ et java . Alors, JVM fera la magie là-bas? Je pense comment C ++ va gérer cela! :)



8
votes

Les modificateurs d'accès sont uniquement un mécanisme d'heure compilé en C ++. En Java Cependant, ils sont également appliqués au moment de l'exécution, car Java dispose également d'un système d'exécution, et il peut créer de manière dynamique (à l'exécution) créer des classes. Il a donc besoin de faire respecter l'accès au moment de l'exécution pour les types qu'il ne sait pas à l'heure de la compilation.

Pourquoi utiliser les modificateurs d'accès?

Le seul but des modificateurs d'accès est de faire respecter la conception.

Dites que vous avez une classe A que vous avez implémenté xxx

et certains code à l'aide de la classe A : < / p> xxx

Le code ci-dessus peut appeler a_obj.dosomething () , mais ils n'ont pas accès direct à MPRivMember, donc A.MPRivRMember écrit de la classe extérieure A ne compilera pas.

Maintenant, pourquoi voudriez-vous que certains membres accessibles au code extérieur et d'autres non? Eh bien, voici la raison pour laquelle: pour le moment, la méthode dossommé () utilise mprivmember pour réellement faire des choses. Mais après un certain temps, vous pouvez décider que vous voulez refacteur le code dans DOSMUSIAT, pour l'améliorer. Vous avez trouvé une façon différente de faire quelque chose qui n'implique pas d'utiliser mprivmember plus. Donc, vous supprimez mprivmember et réimplément DOSOMODIAT une autre manière.

MAINTENANT, s'il y avait du code en dehors de votre classe en utilisant MPRivMember , ce code ne compilerait plus parce que vous avez supprimé mprivmember lors de la réimplanisation DOSMATHIGH . Pour prévenir l'existence de ce code, vous limitez l'accès au MPRivMember . Le mécanisme à faire est à travers les qualificatifs d'accès tels que privé et protégé .

Ceci vous permet de reflicader le code dans L'avenir sans se soucier que d'autres Code utilisent des membres internes.

RECAP

public privé et protégé sont compilés des mécanismes d'heure en C ++. Ils n'existent pas dans la forme binaire générée de votre programme, et donc de telles protections ne sont pas appliquées. Tout est accessible de n'importe où.

en Java Cependant, les classes peuvent être créées au moment de l'exécution si je ne me trompe pas. Quelle est la raison pour laquelle il doit également vérifier l'accès au moment de l'exécution aussi afin qu'il puisse les appliquer, donc privé public et protégé existe un binaire Java.


3 commentaires

Pensez-vous que cela pourrait être utile si nous les avons en binaire aussi? Pourrait-il être utile dans tous les cas?


Non, puisque les binaires ne sont pas censés être modifiés sous cette forme. Et un binaire ne sera pas généré si les droits d'accès sont violés dans un code source en premier lieu, en raison de la compilation des erreurs de temps, la mise en place de tels mécanismes d'application dans un binaire s'en brûler inutilement et ajouterait des frais généraux et être redondant.


@MAHDI Notez que dans Java, les modificateurs d'accès existent sur la forme binaire. J'ai mis à jour la section de récapitulatif de ma réponse pour expliquer pourquoi.



1
votes

Code C ++ compilé n'a aucun concept de privé / protégé / public. Il tombe au code de la machine, qui n'a pas de concept de celles-ci. Sans support natif pour cela, comment pourriez-vous les soutenir? Mieux encore, comment pouvez-vous même faire un soutien natif pour cela.

Les modificateurs d'accès sont destinés aux humains, pas pour les machines. Les modificateurs d'accès sont un aspect conception , et non un aspect de sécurité.

tl; dr : au moment où le code C ++ est en train d'exécuter la machine n'a aucune idée privée / publique / protégée existait jamais.


3 commentaires

Je pensais qu'il pourrait y avoir un mécanisme comme une table d'accès incluse dans le binaire, vérifiant les droits ...


@Mahdi Nope :). Cela ajouterait une énorme performance frappée pour ajouter quelque chose comme ça à ce faible niveau de niveau. Vous devez essentiellement faire une recherche supplémentaire pour tout code. Cela signifierait une énorme diminution de la performance. (En outre, il faudrait littéralement être fait à un niveau matériel. Sinon, comment arrêtez-vous le code de simplement sauter à une adresse «privée»? En fait, maintenant que je pense à cela ... Je n'ai aucune idée du tout comment vous pourrait mettre en œuvre de vrai privé / public / protégé sans différents espaces d'adresses ni tables de recherche fou.)


Oh oui! Je vois ce que tu veux dire! Nous avons besoin de processeurs OOP ...: D