W metodach klasy GoldCustomer dostępne są tylko pola public class Customer {
public string Name;
protected int Id;
private int Age;
}
public class GoldCustomer: Customer {
private GoldPoints: int;
}
Ta odpowiedź dobrze pokazuje, jak działa dziedziczenie i modyfikatory dostępu w C#. W klasie GoldCustomer masz dostęp do własnych pól, czyli GoldPoints, oraz do pól odziedziczonych po klasie bazowej Customer. Tutaj kluczowe jest rozumienie, które pola są faktycznie dostępne. Skoro Name jest publiczne, to bez żadnych kombinacji można się do niego dobrać z dowolnego miejsca – nawet spoza klasy. Id jest chronione (protected), więc według zasad OOP dostępne jest w klasie bazowej oraz wszystkich pochodnych – czyli właśnie w GoldCustomer. To bardzo praktyczne, bo często się zdarza, że potrzebujemy pracować na polach z klasy bazowej, ale nie chcemy, żeby były one widoczne na zewnątrz klasy (np. przez innych programistów korzystających z API). Age jest prywatne i tu już nie da się go bezpośrednio użyć w klasie pochodnej. Z mojego doświadczenia korzystanie z protected dla rzeczy, które mają być dostępne tylko w hierarchii dziedziczenia, to codzienność – pozwala zachować elastyczność, ale i bezpieczeństwo enkapsulacji. Praktycznie rzecz biorąc, jak piszesz klasy dziedziczące po innych, zawsze warto zerknąć na poziomy dostępu, bo od nich zależy, do czego masz dostęp i co możesz odziedziczyć. Wzorce projektowe, jak np. Template Method, mocno polegają na mechanizmach dziedziczenia i odpowiedniego ustawienia widoczności pól czy metod. Przemyślany dobór public, protected, private ułatwia utrzymanie kodu oraz chroni przed przypadkowym wykorzystaniem nieodpowiednich elementów klasy, co w większych projektach bywa naprawdę kluczowe.
W tym pytaniu nietrudno pomylić się, bo różnice między public, protected i private czasem wydają się nieintuicyjne – szczególnie jak ktoś dopiero zaczyna przygodę z C#. Najczęstszy błąd to założenie, że wszystkie pola klasy bazowej są automatycznie dostępne w klasach pochodnych. Tak jednak nie jest. Publiczne pole (takie jak Name) będzie widoczne absolutnie wszędzie – także w GoldCustomer. Protected (Id) daje dostęp tylko klasie bazowej i pochodnym, co jest bardzo wygodne przy dziedziczeniu, bo pozwala korzystać z ważnych danych bez upubliczniania ich na zewnątrz. Natomiast private (Age) jest dostępne wyłącznie w ramach klasy, w której zostało zadeklarowane – żadna klasa pochodna nie może go bezpośrednio użyć. W praktyce programistycznej wiele osób myli protected z public, przez co zdarza się, że do protected próbują się dostać spoza klasy dziedziczącej – i wtedy pojawia się frustracja. Z kolei pole GoldPoints zostało zadeklarowane bezpośrednio w GoldCustomer i dzięki temu jest dostępne tylko w tej klasie – nawet inne klasy dziedziczące po GoldCustomer nie będą miały do niego dostępu. Jeśli chodzi o Age, wielu początkujących (i nie tylko!) zakłada, że dziedziczenie daje pełen dostęp do wszystkiego z klasy bazowej, ale to nieprawda – private jest całkowicie zamknięte. Z technicznego punktu widzenia, zrozumienie tej różnicy pozwala nie tylko lepiej projektować własne klasy, ale i unikać błędów, które potem trudno wyłapać, zwłaszcza w większych projektach. Tak więc, praktyka pokazuje, że najbezpieczniejsze jest świadome korzystanie z modyfikatorów dostępu – pomaga to zachować porządek i minimalizuje ryzyko przypadkowych błędów podczas rozwoju aplikacji.