Dieser Artikel behandelt das grundlegendste Konzept der objektorientierten Programmierung aus der Perspektive der Programmiersprache C#. Das Konzept ist als „Zugriffsmodifikatoren“ bekannt. Die allererste zu beantwortende Frage lautet: Was sind Zugriffsmodifikatoren? Einfach ausgedrückt steuern Zugriffsmodifikatoren, auf welche Objekte/Variablen/Konstanten/Methoden (praktisch alles) in welchem Teil des Codes zugegriffen werden kann. Zugriffsmodifikatoren spielen eine wichtige Rolle beim Nachweis des Konzepts der Abstraktion in der objektorientierten Programmierung. Sie steuern, welcher Teil des Programms für den Endbenutzer sichtbar sein soll und welcher nicht. Natürlich ist ein Endbenutzer am wenigsten besorgt über die Konstanten und Variablen, die am Algorithmus beteiligt sind. Es geht ihm nur darum, welche Methode er aufrufen muss, um die Ausgabe zu erhalten.
C# stellt uns vier Arten von Zugriffsmodifikatoren zur Verfügung:
Neben diesen vier Zugriffsmodifikatoren gibt es zwei weitere Zugriffsebenenkombinationen–
Lassen Sie uns jedes anhand eines Beispiels verstehen.
Privat ist die Zugriffsebene mit den höchsten Einschränkungen. Es ist auch der Standardzugriffsmodifikator für alle Konstanten, Variablen, benutzerdefinierten Objekte usw. Standardmäßig sind nur Aufzählungen und Schnittstellen öffentlich. Wenn Sie also keinen Zugriffsmodifikator angeben, weist C# ihm den Standardmodifikator zu.
Auf private Objekte kann außerhalb des Hauptteils der Klasse oder Struktur oder des Programmabschnitts, in dem sie deklariert sind, nicht zugegriffen werden. Jeder Versuch, auf das Objekt außerhalb des Bereichs des Hauptteils zuzugreifen, in dem es deklariert ist, führt zu einem Fehler bei der Kompilierung.
Beispiel #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);
}
}Ausgabe:
Beispiel #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);
}
}Ausgabe:
Der geschützte Zugriffsspezifizierer beschränkt den Zugriff auf ein Objekt nur von abgeleiteten Instanzen der Klasse. Wenn also ein untergeordnetes Klassenobjekt versucht, auf die geschützten Objekte einer übergeordneten Klasse zuzugreifen, ist dies zulässig. Nicht abgeleitete Klassen können nicht auf geschützte Mitglieder einer Klasse zugreifen. Natürlich sind geschützte Objekte für Methoden ihrer eigenen Klasse zugänglich.
Beispiel:
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);
}
}Ausgabe:
Dies ist der am wenigsten eingeschränkte Zugriffsmodifikator. Öffentliche Objekte sind praktisch für die gesamte Außenwelt zugänglich und stellen damit den höchstzulässigen Zugriffsmodifikator dar. Dies ist natürlich mit hohen Kosten verbunden – den Kosten des geringsten Schutzes.
Jeder Teil des Codes kann auf öffentliche Mitglieder zugreifen. Dadurch sind sie am wenigsten sicher. Jede Codelogik kann ihren Wert ändern, was zu unerwartetem Verhalten führen kann. Daher muss man sehr vorsichtig sein, bevor man ein Objekt veröffentlicht.
Wenn wir in derselben Employee-Klasse, die wir in unserem Beispiel für einen privaten Zugriffsmodifikator erstellt haben, die Zugriffsebene der Öffentlichkeit ändern, benötigen wir keine Getter- und Setter-Methoden. Tatsächlich besteht die beste Vorgehensweise darin, das Objekt privat zu machen und C#-Getter- und Setter-Eigenschaften zu verwenden.
Beispiel:
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);
}
}Ausgabe:
Auf interne Objekte und Methoden kann nur innerhalb derselben Assembly zugegriffen werden. Dies ist ein sehr nützlicher Zugriffsmodifikator, wenn Sie ein Objekt öffentlich machen und seinen Zugriff dennoch nur auf das Framework beschränken möchten, das Sie codieren.
Im Wesentlichen sind also alle internen Objekte für alle Bereiche derselben Baugruppe zugänglich.
Lassen Sie uns zwei Konsolenanwendungen erstellen, um zu verstehen, wie dies funktioniert.
Beispiel:
Schritt 1: Erstellen Sie eine C#-Konsolenanwendung und fügen Sie den folgenden Code darin ein:
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);
}
}
}Schritt 2: Erstellen Sie die Lösung, um die DLL-Datei aus dem bin-Ordner abzurufen.
Schritt 3: Erstellen Sie eine weitere Konsolenanwendung und verweisen Sie auf die Assemblydatei von ConsoleApp1. Klicken Sie im Bild unten auf „Referenz hinzufügen“ und navigieren Sie zum Speicherort der DLL-Datei aus Schritt 2. Sie muss ~/ConsoleApp1/bin/Debug/ConsoleApp1.dll ähneln.
Nachdem Sie die DLL-Datei hinzugefügt haben, sollten Sie sie unter „Assemblies“ finden.
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.
Das obige ist der detaillierte Inhalt vonZugriffsmodifikatoren in C#. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
