A voir également:
- Protected private
- C# protected - Meilleures réponses
- Private net - Meilleures réponses
- Php protected vs private ✓ - Forum - PHP
- Private sub vb.net ✓ - Forum - VB.NET
- Protected internal c ✓ - Forum - C# / .NET
- Private spice tv en direct - Forum - Visual Basic 6
- Private vba - Forum - Visual Basic
7 réponses
MorpionMx
- Messages postés
- 3466
- Date d'inscription
- lundi 16 octobre 2000
- Statut
- Modérateur
- Dernière intervention
- 30 octobre 2008
Microsoft, par le biais de la plate forme .Net, veux proner la sécurité.
Je crois que ceci amène cela.
Par défaut, tout est private, ainsi si quelqu'un veut heriter une
classe de ton assemblage, il n'aura pas accés a des méthodes ou
variables qui pourrait faire foirer la classes en cas de mauvaise
utilisation.
Il y a surement d'autres explications, mais c'est comme ca que je vois la chose.
Cependant, c'est pas pour ca quil y a "moins de possibilité d'hétitage"
pour reprendre tes mots. Rien ne t'empeche de spécifier ce que tu veux
qui soit accessibles aux classes filles en specifiants tes méthodes et
propriétés en protected.
Mx
Je crois que ceci amène cela.
Par défaut, tout est private, ainsi si quelqu'un veut heriter une
classe de ton assemblage, il n'aura pas accés a des méthodes ou
variables qui pourrait faire foirer la classes en cas de mauvaise
utilisation.
Il y a surement d'autres explications, mais c'est comme ca que je vois la chose.
Cependant, c'est pas pour ca quil y a "moins de possibilité d'hétitage"
pour reprendre tes mots. Rien ne t'empeche de spécifier ce que tu veux
qui soit accessibles aux classes filles en specifiants tes méthodes et
propriétés en protected.
Mx
TheSaib
- Messages postés
- 2368
- Date d'inscription
- mardi 17 avril 2001
- Statut
- Modérateur
- Dernière intervention
- 26 décembre 2007
Microsoft favorise surtout le code "propre"
Des variables privées pour l'instance de la classe.
Des Accesseurs / Propriétés public pour tout le monde
Des Accesseurs / Propriétés protected pour les classes dérivées.
Des Accesseurs / Propriétés internal pour l'assembly en cours.
Dans tout les cas tu ne devrais pas mettre un champs avec une visibilité autre que private.
::|The S@ib|::
MVP C#.NET
Des variables privées pour l'instance de la classe.
Des Accesseurs / Propriétés public pour tout le monde
Des Accesseurs / Propriétés protected pour les classes dérivées.
Des Accesseurs / Propriétés internal pour l'assembly en cours.
Dans tout les cas tu ne devrais pas mettre un champs avec une visibilité autre que private.
::|The S@ib|::
MVP C#.NET
thiosyiasar
- Messages postés
- 186
- Date d'inscription
- lundi 11 mars 2002
- Statut
- Membre
- Dernière intervention
- 30 novembre 2010
C'est dommage que Microsoft voit le développement de cette façon ! Ca confirme une tendance où le développeur devient de moins en moins responsable...<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
Si le programmeur est 'mauvais' ou mal intentionné, rien ne l'empêche de toutes façon d'aller mettre la 'grouille'. Une classe bien documentée fournissant un comportement de base à plus d'utilité qu'une classe (usine à gaz) essayant de tout faire sans exposer une partie de son fonctionnement interne
Maintenant, pour répondre à TheSaid, je n'ai pas la même définition du code propre. C'est plutôt une vision fermée et, c'est vrai, un peu plus sécurisée
Même si il faut rester prudent sur le protected, le private doit rester un cas particulier sinon qu'elle est l'intérêt d'hériter ? Autant encapsuler la classe (oui c'est un peu radical). Enfin c'est mon point de vue.
Non mais dites donc, les développeurs java ont il plus confiance entre eux que les développeurs C# ??? Les développeurs java sont ils plus compétents en conception objet ?
En tout cas merci pour vos réponse, même si nos points de vues sont divergents
Nico
Si le programmeur est 'mauvais' ou mal intentionné, rien ne l'empêche de toutes façon d'aller mettre la 'grouille'. Une classe bien documentée fournissant un comportement de base à plus d'utilité qu'une classe (usine à gaz) essayant de tout faire sans exposer une partie de son fonctionnement interne
Maintenant, pour répondre à TheSaid, je n'ai pas la même définition du code propre. C'est plutôt une vision fermée et, c'est vrai, un peu plus sécurisée
Même si il faut rester prudent sur le protected, le private doit rester un cas particulier sinon qu'elle est l'intérêt d'hériter ? Autant encapsuler la classe (oui c'est un peu radical). Enfin c'est mon point de vue.
Non mais dites donc, les développeurs java ont il plus confiance entre eux que les développeurs C# ??? Les développeurs java sont ils plus compétents en conception objet ?
En tout cas merci pour vos réponse, même si nos points de vues sont divergents
Nico
TheSaib
- Messages postés
- 2368
- Date d'inscription
- mardi 17 avril 2001
- Statut
- Modérateur
- Dernière intervention
- 26 décembre 2007
Déjà : TheSaib pas TheSaid
Je voudrais pas être vexant, mais c'est la base de la POO, et je pense que ta conception est a revoir.
http://deptinfo.unice.fr/~fedou/ENSEIGNEMENT/ASD-MIAGE/JAVAOO/
http://liris.cnrs.fr/julien.ricard/Cours/document2005/cours_2.ppt
http://www.iut-bethune.univ-artois.fr/~caron/courscpp/section2_3_2.html
Et j'ai pris que les premiers de Google.
Dans tout les cas les attributs sont encapsulés. De plus le fait de faire ainsi permet de faire de la vérification de type ou de saisie ce qu'une simple variable protected ne peux pas faire lors de son affectation.
::|The S@ib|::
MVP C#.NET
Je voudrais pas être vexant, mais c'est la base de la POO, et je pense que ta conception est a revoir.
http://deptinfo.unice.fr/~fedou/ENSEIGNEMENT/ASD-MIAGE/JAVAOO/
http://liris.cnrs.fr/julien.ricard/Cours/document2005/cours_2.ppt
http://www.iut-bethune.univ-artois.fr/~caron/courscpp/section2_3_2.html
Et j'ai pris que les premiers de Google.
Dans tout les cas les attributs sont encapsulés. De plus le fait de faire ainsi permet de faire de la vérification de type ou de saisie ce qu'une simple variable protected ne peux pas faire lors de son affectation.
::|The S@ib|::
MVP C#.NET
thiosyiasar
- Messages postés
- 186
- Date d'inscription
- lundi 11 mars 2002
- Statut
- Membre
- Dernière intervention
- 30 novembre 2010
Ooohh t'est un peu prétentieux toi ?
1ere Doc, 1ere Ligne
Attributs
Il sont en général déclarés private pour qu'on ne puisse pas les appeler directement à l'extérieur du fichier qui les définit
Or
Toi c'est plus du genre "c'est un attribut donc c'est privés"
En fait cela signifie. L'attribut est privé pour le cacher aux autres fichiers (classes) extérieur et non aux classes fille.
Il y'a plein de doc sur le web encore faut il savoir les lire.
Sinon on est pas d'accord c'est tout je ne pense pas que t'as façon de voir soit fausse, juste un peu fermé
Un peu de lecture peut être ?
http://penserenjava.free.fr/
Allez.... Ciao !
Nico
1ere Doc, 1ere Ligne
Attributs
Il sont en général déclarés private pour qu'on ne puisse pas les appeler directement à l'extérieur du fichier qui les définit
Or
Toi c'est plus du genre "c'est un attribut donc c'est privés"
En fait cela signifie. L'attribut est privé pour le cacher aux autres fichiers (classes) extérieur et non aux classes fille.
Il y'a plein de doc sur le web encore faut il savoir les lire.
Sinon on est pas d'accord c'est tout je ne pense pas que t'as façon de voir soit fausse, juste un peu fermé
Un peu de lecture peut être ?
http://penserenjava.free.fr/
Allez.... Ciao !
Nico
TheSaib
- Messages postés
- 2368
- Date d'inscription
- mardi 17 avril 2001
- Statut
- Modérateur
- Dernière intervention
- 26 décembre 2007
Je ne vois nul part signe de prétention quelquonque, je n'aime pas qu'on ecorche mes identités
J'ai les mêmes en .NET ...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vbtchooinvbnet.asp
Et en Java :
http://java.sun.com/docs/books/tutorial/java/javaOO/classvars.html
Je ne cherche pas à te convaincre, je ne fait pas de l'évangélisation de quoi que ce soit. Mais je pense que tu auras l'occasion de te rendre compte plus tard de l'impotance de la protection des données et par conséquence de l'intêret de bien caracteriser la portée de tes attributs. Et je t'assure que cela n'a rien a voir avec le : "Je code bien , tu codes mal" ou de confiance réciproque entre développeur.
Maintenant t'en fait ce que tu veux.
::|The S@ib|::
MVP C#.NET
J'ai les mêmes en .NET ...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vbtchooinvbnet.asp
Et en Java :
http://java.sun.com/docs/books/tutorial/java/javaOO/classvars.html
Je ne cherche pas à te convaincre, je ne fait pas de l'évangélisation de quoi que ce soit. Mais je pense que tu auras l'occasion de te rendre compte plus tard de l'impotance de la protection des données et par conséquence de l'intêret de bien caracteriser la portée de tes attributs. Et je t'assure que cela n'a rien a voir avec le : "Je code bien , tu codes mal" ou de confiance réciproque entre développeur.
Maintenant t'en fait ce que tu veux.
::|The S@ib|::
MVP C#.NET
thiosyiasar
- Messages postés
- 186
- Date d'inscription
- lundi 11 mars 2002
- Statut
- Membre
- Dernière intervention
- 30 novembre 2010
Pour la prétention, je parlai de 'je pense que ta conception est a revoir'
On est d'accord sur un point, il faut bien penser la porté des membres d'une classe et ne pas exposer n'importe quoi n'importe comment.
Sinon, t'inquiète je prend vos réponses aux sérieux.
Nico
On est d'accord sur un point, il faut bien penser la porté des membres d'une classe et ne pas exposer n'importe quoi n'importe comment.
Sinon, t'inquiète je prend vos réponses aux sérieux.
Nico