Quel est le cas d'utilisation du modificateur "private protected" (C# 7.2) ?

Question

C# 7.2 introduit le modificateur private protected .

J'ai toujours protégé l'accès aux champs par des propriétés, en autorisant l'accès par les méthodes Get/Set, car je ne veux généralement pas que l'état interne de mon objet soit modifié par autre chose que ma propre classe.

J'essaie de comprendre pourquoi l'équipe du langage C# a ajouté cette fonctionnalité. Après une recherche approfondie sur Google, ainsi que la lecture et le visionnage des médias " quoi de neuf " (j'ai regardé l'émission Communiqué de presse , détails et vidéo de Mads Torgerson ), je ne suis toujours pas le plus sage.

Pour moi, cela semble permettre à un développeur de briser le principe de substitution de Liskov, mais c'est peut-être parce que je ne comprends pas pourquoi cette fonctionnalité existe maintenant.

Je comprends comment il peut être utilisé, mais pas pourquoi - s'il vous plaît, quelqu'un peut-il fournir un exemple d'utilisation réelle plutôt que celui inventé dans les documents MSDN ?

Answer 1

Avant C# 7.2, nous avions protected internal modificateur. Cela signifie en réalité protégé OU interne, c'est-à-dire - membre A est accessible aux classes filles et également à toute classe de l'assemblage courant, même si cette classe n'est pas fille de la classe A (de sorte que la restriction impliquée par "protégé" est relâchée).

private protected signifie en réalité protégé ET interne. En d'autres termes, le membre n'est accessible qu'aux classes enfant qui sont dans la même assemblée, mais pas aux classes enfant qui sont en dehors de l'assemblée (ainsi, la restriction impliquée par "protected" est réduite - elle devient encore plus restrictive). C'est utile si vous construisez une hiérarchie de classes dans votre assembly et que vous ne voulez pas que des classes enfants d'autres assemblies puissent accéder à certaines parties de cette hiérarchie.

Nous pouvons prendre l'exemple suivant Jon Skeet fourni par dans les commentaires . Supposons que vous ayez la classe

public class MyClass {

}

Et vous voulez pouvoir en hériter uniquement dans l'assemblage actuel, mais vous ne voulez pas autoriser l'instanciation directe de cette classe, sauf à partir de cette hiérarchie de classes.

L'héritage uniquement dans l'assemblage actuel peut être réalisé avec le constructeur interne

public class MyClass {
    internal MyClass() {
    }
}

Empêcher l'instanciation directe, sauf dans la hiérarchie de la classe actuelle, peut être réalisé avec un constructeur protégé :

public class MyClass {
    protected MyClass() {
    }
}

Et pour obtenir les deux, vous devez private protected constructeur :

public class MyClass {
    private protected MyClass() {
    }
}

Answer 2

Pour deux mots Les modificateurs d'accès J'ai ce concept - le premier accesseur est lié à un autre assemblage, le second à l'assemblage dans lequel il a été défini.

interne protégé

• protégé dans un autre assemblage : accessible uniquement dans les classes filles.

• interne dans l'assemblée actuelle : accessible par tous les membres de l'assemblée actuelle.

privé protégé

• privé dans une autre assemblée : n'est pas accessible.
• protégé dans l'assemblage courant : accessible uniquement dans les classes filles.

Answer 3

Supposons que vous ayez une classe interne appelée SomeHelper que vous souhaitez utiliser dans le cadre de l'implémentation d'une classe de base abstraite publique :

public abstract class Test
{
    // Won't compile because SomeHelper is internal.
    protected SomeHelper CreateHelper()
    {
        return new SomeHelper();
    }

    public int Func(int x)
    {
        var helper = CreateHelper();
        return helper.DoSomething(x);
    }
}

internal class SomeHelper
{
    public virtual int DoSomething(int x)
    {
        return -x;
    }
}

Cela ne compilera pas car vous ne pouvez pas avoir une méthode protégée retournant un type interne. Votre seul recours est de ne pas utiliser SomeHelper de cette manière, ou de faire SomeHelper public.

(Vous pourriez faire SomeHelper une classe interne protégée de Test mais ça ne marchera pas si SomeHelper est destiné à être utilisé par d'autres classes qui ne dérivent pas de la classe de base).

Avec l'introduction de la private protected vous pouvez déclarer CreateHelper() comme ça :

private protected SomeHelper CreateHelper()
{
    return new SomeHelper();
}

Maintenant, il compilera, et vous n'avez pas à exposer vos internes.