Wprowadzenie do modyfikatorów dostępu w C #

W tym artykule omówiono najbardziej elementarną koncepcję programowania obiektowego z perspektywy języka programowania C #. Koncepcja znana jest jako - modyfikatory dostępu. Pierwsze pytanie, na które należy odpowiedzieć, to: czym są modyfikatory dostępu? Mówiąc najprościej, modyfikatory dostępu kontrolują, które obiekty / zmienne / stałe / metody (praktycznie wszystko) mogą być dostępne w której części kodu. Modyfikatory dostępu odgrywają ważną rolę w sprawdzaniu koncepcji abstrakcji w programowaniu obiektowym. Kontrolują, jaka część programu powinna być i nie powinna być widoczna dla użytkownika końcowego. Oczywiście użytkownik końcowy jest najmniej zaniepokojony stałymi i zmiennymi zaangażowanymi w algorytm. Martwi go tylko to, jaką metodę musi wywołać, aby uzyskać wynik.

Typy modyfikatorów dostępu w C #

C # zapewnia nam cztery typy modyfikatorów dostępu:

  • Prywatny (domyślny modyfikator dostępu, z wyjątkiem wyliczeń i interfejsów)
  • Chroniony (nieznacznie ograniczony)
  • Publiczny (nieograniczony, domyślny wybór dla wyliczeń i interfejsów)
  • Wewnętrzne (publiczne w ramach tego samego zgromadzenia)

Oprócz tych czterech modyfikatorów dostępu istnieją jeszcze dwie kombinacje poziomów dostępu -

  • Chroniony wewnętrzny
  • Prywatny chroniony

Pozwól nam zrozumieć każdy z przykładem.

1. Prywatny

Prywatny to najbardziej ograniczony poziom dostępu. Jest także domyślnym modyfikatorem dostępu dla wszystkich stałych, zmiennych, obiektów zdefiniowanych przez użytkownika itp. Domyślnie tylko wyliczenia i interfejsy są publiczne. Tak więc, jeśli nie określisz żadnego modyfikatora dostępu, C # przypisuje do niego domyślny modyfikator.

Prywatne obiekty nie są dostępne poza treścią klasy, struktury lub sekcji programu, w której zostały zadeklarowane. Każda próba uzyskania dostępu do obiektu poza zakresem treści, w której został zadeklarowany, powoduje błąd kompilacji.

Przykład 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);
)
)

Wyjście 1:

Przykład nr 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);
)
)

Wyjście 2:

2. Chroniony

Specyfikator dostępu chronionego ogranicza dostępność obiektu tylko z pochodnych instancji klasy. Jeśli więc obiekt klasy podrzędnej próbuje uzyskać dostęp do chronionych obiektów klasy nadrzędnej, jest to dozwolone. Klasy niepochodzące nie mogą uzyskać dostępu do chronionych członków dowolnej klasy. Oczywiście chronione obiekty są dostępne dla metod własnej klasy.

Przykład

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);
)
)

Wyjście 3:

3. Publiczny

Jest to najmniejszy modyfikator dostępu. Obiekty publiczne są praktycznie dostępne dla całego świata zewnętrznego, co czyni go najwyższym dopuszczalnym modyfikatorem dostępu. Oczywiście wiąże się to z dużymi kosztami - kosztem najmniejszej ochrony.

Do członków publicznych można uzyskać dostęp za pomocą dowolnej części kodu. To sprawia, że ​​są najmniej bezpieczne. Każda logika kodu może modyfikować ich wartość, co może prowadzić do nieoczekiwanego zachowania. Trzeba więc być bardzo ostrożnym przed upublicznieniem jakiegokolwiek obiektu.

W tej samej klasie pracownika, którą utworzyliśmy w naszym przykładzie modyfikatora prywatnego dostępu, jeśli zmienimy poziom dostępu na publiczny, nie potrzebowalibyśmy żadnych metod Gettera i Settera. W rzeczywistości najlepszą praktyką jest uczynienie obiektu prywatnym i użycie właściwości Gettera i Settera w języku C #.

Przykład

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);
)
)

Wyjście 4:

4. Wewnętrzny

Wewnętrzne obiekty i metody są dostępne tylko w tym samym zestawie. Jest to bardzo przydatny modyfikator dostępu, gdy chcesz upublicznić dowolny obiekt, a jednocześnie ograniczyć jego dostęp tylko do kodowanej struktury.

Zasadniczo wszystkie obiekty wewnętrzne są dostępne dla wszystkich obszarów tego samego zespołu.

Stwórzmy dwie aplikacje konsolowe, aby zrozumieć, jak działa.

Przykład

Krok 1: Utwórz aplikację konsoli C # i umieść w niej poniższy kod:

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);
)
)
)

Krok 2: Zbuduj rozwiązanie, aby pobrać plik .dll z folderu bin.

Krok 3: Utwórz kolejną aplikację konsoli i odwołaj się do pliku asemblera z ConsoleApp1. Kliknij Dodaj odniesienie na obrazku poniżej i przejdź do lokalizacji pliku .dll z kroku 2. Musi być podobny do ~ / ConsoleApp1 / bin / Debug / ConsoleApp1.dll.

Po dodaniu pliku DLL należy go znaleźć w części Zespoły.

Krok 4: Umieść poniższy kod w 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);
)
)
)

Krok 5: Kiedy budujesz ConsoleApp2, pojawia się błąd czasu kompilacji wskazujący, że „x” z ConsoleApp1 nie jest dostępny w innych zestawach ze względu na jego poziom ochrony.

5. Chroniony wewnętrzny

Jest to kombinacja zarówno chronionego, jak i wewnętrznego modyfikatora dostępu. Ważną koncepcją do zrozumienia tutaj jest to, że Protected Internal oznacza Protected OR Internal. Jest to połączenie obu modyfikatorów dostępu. To nigdy nie powinno być uważane za skrzyżowanie.

Zatem obiekty wewnętrzne nie są dostępne poza zestawem, natomiast obiekty chronione są dostępne dla dowolnej klasy pochodnej w dowolnym zestawie. Co jeśli chcę chronić mój obiekt tylko w innych zespołach, a nie w tym samym zestawie? Proste rozwiązanie - zadeklaruj to jako wewnętrznie chronione.

Przykład

Krok 1: Zmodyfikujmy naszą ConsoleApp1, aby odzwierciedlić poniższy kod. Zauważ, że zmieniliśmy poziom dostępu naszej zmiennej „x” na chroniony wewnętrzny.

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);
)
)
)

Krok 2: Zbuduj rozwiązanie ponownie i zamień .dll w ConsoleApp2 na zaktualizowane.

Krok 3: Zaktualizuj kod w ConsoleApp2, jak poniżej:

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();
)
)
)

Krok 4: Uruchom ConsoleApp2, aby zobaczyć dane wyjściowe.

6. Prywatne chronione

Jest to połączenie modyfikatorów zarówno prywatnego, jak i chronionego dostępu. Chroniony wewnętrzny oznacza chroniony LUB wewnętrzny. Tak więc obiekty prywatne nie są dostępne poza blokiem kodu, w którym są zadeklarowane, natomiast obiekty chronione są dostępne dla dowolnej klasy pochodnej w dowolnym zestawie. Co jeśli chcę ograniczyć dostęp do mojego obiektu nawet w klasach pochodnych w innych złożeniach? Proste rozwiązanie - zadeklaruj to jako wewnętrznie chronione.

Przykład

Zmodyfikujmy poziom dostępu „x” w ConsoleApp1 na 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();
)
)
)

Wynik:

Porównanie tabelaryczne

Specyfikator dostępu To samo zgromadzenie Inne zgromadzenie
Sama klasaKlasy pochodnejKlasa niepochodzącaKlasy pochodnejKlasa niepochodząca
PrywatnytakNieNieNieNie
Publicznytaktaktaktaktak
ChronionytaktakNietakNie
WewnętrznytaktaktakNieNie
Chroniony wewnętrznytaktaktaktakNie
Prywatny chronionytaktakNieNieNie

Wniosek

W powyższym artykule widzieliśmy, że modyfikatory dostępu kontrolują dostęp do wszystkiego w projekcie. Różne kombinacje poziomów dostępu pokrywają potrzeby różnych rodzajów dostępności. Programiści muszą mądrze wybrać, mając na uwadze bezpieczeństwo i absolutną konieczność, aby obiekt był dostępny w określonym bloku kodu.

Polecane artykuły

Jest to przewodnik po modyfikatorach dostępu w języku C #. Tutaj omówiliśmy typy wprowadzające modyfikatory dostępu w C # wraz z przykładami i wyjściami. Możesz także przejrzeć nasze inne sugerowane artykuły, aby dowiedzieć się więcej -

  1. Kompilatory C #
  2. Niszczyciel w C #
  3. Co to jest TypeScript?
  4. Co to są usługi sieciowe ASP.Net?
  5. Dostęp do modyfikatorów w PHP
  6. Praca i 3 najlepsze metody wyliczania w C #