Modyfikator dostępu znajdujący się przed definicją metody Dodaj() w klasie Kalkulator sprawia, że: protected void Dodaj() {}
Modyfikator protected w językach takich jak C# czy Java oznacza, że metoda jest dostępna zarówno w tej samej klasie, jak i w każdej klasie, która po niej dziedziczy — niezależnie od tego, w którym miejscu projektu ta klasa pochodna się znajduje. To jest bardzo praktyczne, bo pozwala pisać tzw. szkieletowe klasy bazowe, udostępniając pewne funkcjonalności tylko klasom potomnym, a jednocześnie ukrywając je przed kodem zewnętrznym. Takie podejście umożliwia budowanie bezpiecznych i elastycznych struktur dziedziczenia, gdzie konkretne działania mogą być modyfikowane lub rozszerzane tylko tam, gdzie trzeba. Bardzo często spotyka się protected w dużych projektach, gdzie kluczowe funkcje mają być używane wyłącznie w rodzinie klas, a nie dostępne dla całego świata. Moim zdaniem, to świetny sposób na wymuszanie architektury i porządku w kodzie, no bo wiadomo, jak każdy miałby dostęp do wszystkiego, to zaraz byłby bałagan. Przykład praktyczny: pisząc klasę bazową Kalkulator, możesz mieć protected Dodaj(), a publicznie udostępnić tylko ogólną metodę Oblicz(). Dzięki temu masz większą kontrolę, co i jak jest wykorzystywane. Branżowo przyjęło się, że protected to taki złoty środek pomiędzy public a private, gwarantując odpowiednią enkapsulację i możliwość dziedziczenia. Warto to stosować świadomie, żeby potem nie mieć niespodzianek w dużych projektach.
Często spotykanym problemem przy analizie modyfikatorów dostępu jest mylenie zakresów widoczności protected z innymi, jak public, private czy nawet internal. Przekonanie, że protected sprawia, iż metoda staje się dostępna w programie głównym (np. przez obiekt klasy Kalkulator), wynika zazwyczaj z utożsamiania protected z public. Tymczasem protected ogranicza dostępność tylko do klasy bazowej oraz jej pochodnych, więc próba wywołania Dodaj() na przykład bezpośrednio w programie głównym zakończy się błędem kompilacji – chyba że korzystamy z tej metody właśnie w klasie dziedziczącej. Zdarza się także mylić protected z private — niektórzy sądzą, że protected blokuje dostęp w klasach dziedziczących, ale to nieprawda: w przeciwieństwie do private, protected wręcz otwiera drzwi potomnym do korzystania z tych elementów. Jeszcze rzadziej, ale czasem pojawia się myśl, że protected umożliwia dostęp zaprzyjaźnionym klasom, jak w C++, jednak w C# czy Javie pojęcie „klas zaprzyjaźnionych” nie istnieje, więc taki scenariusz odpada. Moim zdaniem cała ta zawiłość bierze się z różnic między językami i zbyt powierzchownej nauki teorii, gdzie nie przykłada się uwagi do praktycznych przykładów użycia. W branży dobra praktyka to właśnie stosowanie protected wtedy, gdy chcemy umożliwić dziedziczenie i rozbudowę funkcji, ale nie udostępniać ich całemu światu. Warto zapamiętać, że protected to narzędzie do zachowania porządku i kontroli dostępu w hierarchii klas — i nie należy go mylić ani z nadmierną dostępnością, ani z pełnym ukrywaniem implementacji.