Cet article couvre le concept le plus élémentaire de la programmation orientée objet du point de vue du langage de programmation C#. Le concept est connu sous le nom de – Modificateurs d’accès. La toute première question à laquelle il faut répondre est la suivante : que sont les modificateurs d’accès ? En termes simples, les modificateurs d'accès contrôlent quels objets/variables/constantes/méthodes (pratiquement tout) sont accessibles dans quelle partie du code. Les modificateurs d'accès jouent un rôle important dans la vérification du concept d'abstraction dans la programmation orientée objet. Ils contrôlent quelle partie du programme doit être et ne doit pas être visible pour l'utilisateur final. Bien entendu, l’utilisateur final est le moins préoccupé par les constantes et les variables impliquées dans l’algorithme. Il se préoccupe uniquement de la méthode qu'il doit invoquer pour obtenir le résultat.
C# nous propose quatre types de modificateurs d'accès :
En dehors de ces quatre modificateurs d'accès, il existe deux autres combinaisons de niveaux d'accès–
Comprenons chacun avec un exemple.
Privé est le niveau d'accès le plus restreint. C'est également le modificateur d'accès par défaut pour toutes les constantes, variables, objets définis par l'utilisateur, etc. Seules les énumérations et les interfaces sont publiques par défaut. Ainsi, si vous ne spécifiez aucun modificateur d'accès, C# lui attribue le modificateur par défaut.
Les objets privés ne sont pas accessibles en dehors du corps de la classe, de la structure ou de la section de programme dans laquelle ils sont déclarés. Toute tentative d'accès à l'objet en dehors de la portée du corps dans lequel il est déclaré entraîne une erreur de compilation.
Exemple n°1
using System; class Employee //private by default { string name; //private by default public string GetName() { return name; } public void SetName(string name) { this.name = name; } } public class Program { public static void Main() { Employee emp = new Employee(); emp.SetName("John"); Console.Write("Employee name is " + emp.GetName()); // compile time error - 'Employee.name' is inaccessible due to its protection level // Console.Write("Employee name is " + emp.name); } }
Sortie :
Exemple n°2
using System; public class Program { public static void Main() { int x = 5; //private to the Main method, accessible inside nested code blocks in the Main method if (true) { int y = 10; //private to the if block, not accessible outside if block Console.WriteLine("x = " + x); Console.WriteLine("y = " + y); } Console.WriteLine("x = " + x); // compile-time error - The name 'y' does not exist in the current context. // Console.WriteLine("y = " + y); } }
Sortie :
Le spécificateur d'accès protégé restreint l'accès d'un objet uniquement à partir d'instances dérivées de la classe. Ainsi, si un objet de classe enfant tente d’accéder aux objets protégés d’une classe parent, cela est autorisé. Les classes non dérivées ne peuvent accéder aux membres protégés d’aucune classe. Bien entendu, les objets protégés sont accessibles aux méthodes de leur propre classe.
Exemple :
using System; class Parent { protected string x; public Parent() { x = "abc"; //accessible to own class methods } } class Child : Parent // derived class { public static void Main() { var parentObj = new Parent(); var childObj = new Child(); Console.WriteLine(childObj.x); //accessible to derived class object instances // compile-time error - Cannot access protected member 'Parent.x' via a qualifier of type 'Parent'; the qualifier must be of type 'Child' (or derived from it) // Console.WriteLine(parentObj.x); } }
Sortie :
C'est le modificateur d'accès le moins restreint. Les objets publics sont pratiquement accessibles à l'ensemble du monde extérieur, ce qui en fait le modificateur d'accès autorisé le plus élevé. Bien sûr, cela a un coût élevé – le coût d’une moindre protection.
N'importe quelle partie du code peut accéder aux membres publics. Cela les rend les moins sécurisés. Toute logique de code peut modifier leur valeur, ce qui peut entraîner un comportement inattendu. Il faut donc être très prudent avant de rendre public un objet.
Dans la même classe Employee que nous avons créée dans notre exemple de modificateur d'accès privé, si nous modifions le niveau d'accès du public, nous n'aurions besoin d'aucune méthode Getter et Setter. En fait, la meilleure pratique consiste à rendre l'objet privé et à utiliser les propriétés C# Getter et Setter.
Exemple :
using System; class Employee { public string name; } public class Program { public static void Main() { Employee emp = new Employee(); emp.name = "John"; Console.Write("Employee name is " + emp.name); } }
Sortie :
Les objets et méthodes internes ne sont accessibles qu’au sein du même assembly. Il s'agit d'un modificateur d'accès très utile lorsque vous souhaitez rendre un objet public tout en limitant son accès uniquement au framework que vous codez.
Donc, en substance, tous les objets internes sont accessibles par toutes les zones du même assemblage.
Créons deux applications console pour comprendre ce fonctionnement.
Exemple :
Étape 1 : Créez une application console C# et placez-y le code ci-dessous :
using System; namespace ConsoleApp1 { public class Parent { internal int x; public Parent() { x = 10; } } public class Program { public static void Main() { var parentObj = new Parent(); // accessible within the same assembly Console.Write("The value of x = " + parentObj.x); } } }
Étape 2 : Créez la solution pour obtenir le fichier .dll du dossier bin.
Étape 3 : Créez une autre application console et référencez le fichier d'assemblage à partir de ConsoleApp1. Cliquez sur Ajouter une référence dans l'image ci-dessous et accédez à l'emplacement du fichier .dll à partir de l'étape 2. Il doit être similaire à ~/ConsoleApp1/bin/Debug/ConsoleApp1.dll.
Après avoir ajouté le fichier .dll, vous devriez le trouver sous Assemblages.
Step4: Place the below code in ConsoleApp2.
using System; using ConsoleApp1; //referencing the first assembly namespace ConsoleApp2 { class Program { static void Main(string[] args) { var parentObj = new Parent(); //not accessible outside the assembly Console.Write(parentObj.x); } } }
Step5: When you build ConsoleApp2, you will get a compile-time error indicating that ‘x’ from ConsoleApp1 cannot be accessed in other assemblies due to its protection level.
This is a combination of both Protected and Internal access modifiers. An important concept to understand here is that Protected Internal means Protected OR Internal. It is a union of both access modifiers. It must never be thought to be an intersection.
So, Internal objects are not accessible outside the assembly, while Protected objects are accessible to any derived class in any assembly. What if I want to protect my object only in other assemblies and not in the same assembly? Simple solution – declare it as protected internal.
Example:
Step 1: Let us modify our ConsoleApp1 to reflect the code below. Notice we have changed the access level of our variable ‘x’ to protected internal.
using System; namespace ConsoleApp1 { public class Parent { protected internal int x; public Parent() { x = 10; } } public class Program { public static void Main() { var parentObj = new Parent(); // accessible within the same assembly Console.Write("The value of x = " + parentObj.x); } } }
Step 2: Build the solution again and replace the .dll in ConsoleApp2 with the updated one.
Step 3: Update the code in ConsoleApp2 as below:
using System; using ConsoleApp1; //referencing the first assembly namespace ConsoleApp2 { class Program: Parent { static void Main(string[] args) { var progObj = new Program(); //accessible only via an object of the derived class. Console.Write(progObj.x); Console.Read(); } } }
Step 4: Run ConsoleApp2 to see the output.
This is a union combination of both Private and Protected access modifiers. Protected Internal means Protected OR Internal. So, Private objects are not accessible outside the code block in which it is declared, while Protected objects are accessible to any derived class in any assembly. What if I want to restrict my object’s access even in derived classes in other assemblies? Simple solution – declare it as protected internal.
Example:
Let us modify the access level of ‘x’ in ConsoleApp1 to Private Protected.
using System; namespace ConsoleApp1 { public class Parent { private protected int x; public Parent() { x = 10; } } public class Child: Parent { public void DisplayX() { // accessible only via derived class objects Console.Write("Value of x = " + x); } } public class Program { public static void Main() { var childObj = new Child(); childObj.DisplayX(); Console.Read(); } } }
Output:
Following is a tabular comparison of Access Modifiers in C#:
Access Specifier | Same Assembly | Other Assembly | |||
Same Class | Derived Class | Non-Derived Class | Derived Class | Non-Derived Class | |
Private | Yes | No | No | No | No |
Public | Yes | Yes | Yes | Yes | Yes |
Protected | Yes | Yes | No | Yes | No |
Internal | Yes | Yes | Yes | No | No |
Protected Internal | Yes | Yes | Yes | Yes | No |
Private Protected | Yes | Yes | No | No | No |
We have seen in the above article that access modifiers control the access of everything in the project. Various combinations of access levels cover the needs of various kinds of accessibility. The developers must choose wisely, keeping in mind the security and the absolute necessity of the object to be accessible in a certain block of code.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!