Quels sont les avantages à définir des méthodes comme "protégées" en C#? aime:méthodes "protégées" en C#?
protected void KeyDemo_KeyPress(object sender, KeyPressEventArgs e)
{
// some code
}
Par rapport à quelque chose comme ceci:
private void FormName_Click(object sender, EventArgs e)
{
//some code
}
Je l'ai vu dans les livres de nombreux exemples et je ne comprends pas pourquoi et quand ont-ils privés et protégés?
Les méthodes protégées peuvent être appelées à partir de classes dérivées. Les méthodes privées ne peuvent pas.
C'est la seule et unique différence entre les méthodes privées et protégées.
Résumait très bien. – Zaki
Cela aurait dû être marqué comme la réponse acceptée! ;) Il est important de réaliser que 'protected' est un modificateur d'accès. Voici une comparaison de tous: http://msdn.microsoft.com/en-us/library/ba0a1yw2.Pour tous les modificateurs: http://msdn.microsoft.com/fr-fr/library/6tcf2h8w.aspx –
Certains aspects de .NET tels que ASP.NET créent des sous-classes de votre classe code-behind lors de l'exécution. Ainsi, une classe ASP.NET Page hérite par exemple de sa classe codebehind. En rendant la méthode protégée, la classe de page générée dynamiquement peut facilement connecter un événement de clic de bouton à une méthode protégée dans la classe de base qui le gère.
Ceci est un exemple raisonnable d'un cas particulier où "protégé" est utilisé, mais pas répondre au fait que l'exemple est aussi une portée * extrêmement * étroite de ce qui est protégé. –
Si vous avez un formulaire hérité (ou n'importe quelle classe d'ailleurs), vous pourrez invoquer cette fonction depuis la sous-classe.
Souvent 'protected' est utilisé lorsque vous voulez qu'une classe enfant remplace une méthode par ailleurs 'private'.
public class Base {
public void Api() {
InternalUtilityMethod();
}
protected virtual void InternalUtilityMethod() {
Console.WriteLine("do Base work");
}
}
public class Derived : Base {
protected override void InternalUtilityMethod() {
Console.WriteLine("do Derived work");
}
}
Nous avons donc le comportement de substitution que nous connaissons et aimons de l'héritage, sans exposer inutilement la InternalUtilityMethod à quiconque en dehors de nos classes.
var b = new Base();
b.Api(); // returns "do Base work"
var d = new Derived();
d.Api(); // returns "do Derived work"
Ceci est incorrect. protégé! = virtuel. Les méthodes doivent être * virtuelles * pour les remplacer dans une classe dérivée. Une méthode virtuelle peut être protégée, mais elle peut aussi être publique ou interne. Une méthode protégée ne peut pas être substituée à moins qu'elle ne soit virtuelle. – Josh
Vous avez raison, j'aurais dû aussi les marquer virtuels. Avec cette faute de frappe, je crois toujours qu'il s'agit d'un cas d'utilisation courant pour «protégé». Je vais éditer le code ci-dessus ... – Bruce
Non, c'est un cas d'utilisation courant pour "virtuel". La question concerne "protégé", pas "virtuel". – Mark
Gardez cela à esprit aussi: Si vous avez un bouton et OnClick est réglé sur Button_Click
<asp:Button id="btn" runat="server" OnClick="Button_Click" />
de ce bouton alors la méthode Button_Click a besoin d'avoir une visibilité au moins protégée pour être accessible par le bouton.
Vous pouvez contourner ce problème en ajoutant ce qui suit pour vous méthode Page_Load:
btn.Click += new EventHandler(Button_Click);
mais dans ces exemples de ce livre il n'y a pas d'héritage. – Sherif
plz je ne peux pas comprendre nous qu'ils l'ont fait .... – Sherif
Pouvez-vous dériver un formulaire de cette classe? Ensuite, vous voudrez peut-être appeler KeyDemo_KeyPress de cette classe, ce qui serait impossible si c'était privé. Mais comme vous ne voulez pas que d'autres classes puissent accéder à la fonction, elle ne peut pas être publique. Par conséquent, il est protégé. – HVS