Modyfikatory dostępu

Część sekcji Programowanie obiektowe ścieżki C# w Coddy. Lekcja 31 z 70.

Modyfikatory dostępu określają, kto może widzieć i używać składowych Twojej klasy. Stanowią podstawę enkapsulacji — jednej z głównych zasad programowania obiektowego. Ograniczając dostęp, chronisz swoje dane i wyznaczasz jasne granice w kodzie.

C# udostępnia cztery główne modyfikatory dostępu:

public class BankAccount
{
    public string AccountHolder;      // Dostępne z dowolnego miejsca
    private decimal balance;          // Tylko w obrębie tej klasy
    protected string accountType;     // Ta klasa i klasy pochodne
    internal int branchCode;          // W obrębie tego samego zestawu
}

Elementy public są dostępne z dowolnego kodu.

Do składowych private można uzyskać dostęp tylko w obrębie tej samej klasy — to najbardziej restrykcyjny poziom dostępu i domyślny dla składowych klasy.

protected umożliwia dostęp z samej klasy oraz z każdej klasy, która po niej dziedziczy.

internal ogranicza dostęp do kodu w obrębie tego samego zestawu (projektu).

Gdy nie określono modyfikatora, elementy klasy domyślnie mają dostęp private:

class Example
{
    int secret;  // domyślnie prywatne
}

Wybór odpowiedniego poziomu dostępu polega na udostępnianiu tylko tego, co jest niezbędne. Zacznij od private i zwiększ widoczność tylko wtedy, gdy masz ku temu konkretny powód. Dzięki temu inny kod nie będzie zależny od szczegółów implementacji, które możesz chcieć zmienić w przyszłości.

Wyzwanie

Łatwy

Stwórzmy bezpieczny system profili użytkowników, który pokaże, jak modyfikatory dostępu chronią poufne dane, udostępniając tylko to, co niezbędne. Utworzysz klasę, w której różne informacje mają różne poziomy widoczności — zależnie od tego, kto powinien mieć do nich dostęp.

Rozmieścisz kod w trzech plikach:

UserProfile.cs: Utwórz klasę UserProfile w przestrzeni nazw Security, która zarządza informacjami o użytkowniku z odpowiednimi poziomami dostępu. Profil powinien zawierać:
- Właściwość public Username (string) — każdy może zobaczyć nazwę użytkownika
- Pole private password (string) — dostęp do niego powinna mieć tylko sama klasa
- Pole protected email (string) — dostęp do niego ma klasa i jej klasy pochodne
- Pole internal userId (int) — dostępne w obrębie tego samego zestawu
Dodaj konstruktor przyjmujący username, password, email i userId. Dodaj metodę public o nazwie GetPublicInfo(), która zwraca "User: {Username}". Dodaj kolejną metodę public o nazwie ValidatePassword(string input), która zwraca true, jeśli dane wejściowe są zgodne z prywatnym hasłem, a w przeciwnym razie false.
AdminProfile.cs: Utwórz klasę AdminProfile w przestrzeni nazw Security, która dziedziczy po UserProfile. Ta klasa pokazuje, jak składowe protected stają się dostępne w klasach pochodnych. Konstruktor powinien przyjmować te same cztery parametry i przekazywać je do konstruktora klasy bazowej. Dodaj metodę public o nazwie GetAdminInfo(), która zwraca "Admin: {Username}, Email: {email}" — zwróć uwagę, że możesz tutaj uzyskać dostęp do chronionego pola email!
Program.cs: W pliku głównym utwórz obiekty UserProfile i AdminProfile, używając wartości wejściowych. Zademonstruj poziomy dostępu, wywołując dostępne metody publiczne i uzyskując bezpośredni dostęp do pola internal (ponieważ znajdujesz się w tym samym zestawie). Pokaż, jakie informacje może ujawnić każdy typ użytkownika.

Otrzymasz pięć danych wejściowych:

Nazwa użytkownika
Hasło
E-mail
Identyfikator użytkownika (liczba całkowita)
Próba podania hasła do weryfikacji

Wypisz dane wyjściowe w tym formacie:

Regular User:
{GetPublicInfo() result}
Internal ID: {userId}
Password valid: {ValidatePassword result}
Admin User:
{GetAdminInfo() result}

Na przykład, jeśli danymi wejściowymi są alice, secret123, alice@email.com, 1001 i secret123, dane wyjściowe powinny wyglądać tak:

Regular User:
User: alice
Internal ID: 1001
Password valid: True
Admin User:
Admin: alice, Email: alice@email.com

Zwróć uwagę, że hasło pozostaje całkowicie ukryte — możesz je jedynie zweryfikować, nigdy odczytać. E-mail jest chroniony, więc może go ujawnić tylko AdminProfile (klasa pochodna). Pole internal userId jest dostępne z pliku głównego, ponieważ znajduje się on w tym samym zestawie. Tak właśnie działa hermetyzacja!

Spróbuj swoich sił

using System;
using Security;

class Program
{
    public static void Main(string[] args)
    {
        // Wczytaj dane wejściowe
        string username = Console.ReadLine();
        string password = Console.ReadLine();
        string email = Console.ReadLine();
        int userId = Convert.ToInt32(Console.ReadLine());
        string passwordAttempt = Console.ReadLine();

        // TODO: Utwórz obiekt UserProfile z wartościami wejściowymi

        // TODO: Utwórz obiekt AdminProfile z tymi samymi wartościami wejściowymi

        // TODO: Wypisz "Regular User:"

        // TODO: Wypisz wynik GetPublicInfo()

        // TODO: Wypisz "Internal ID: ", a następnie pole userId (dostępne, ponieważ znajduje się w tym samym zestawie)

        // TODO: Wypisz "Password valid: ", a następnie wynik ValidatePassword()

        // TODO: Wypisz "Admin User:"

        // TODO: Wypisz wynik GetAdminInfo()
    }
}