2010-06-06 10 views
5

Co było uzasadnieniem wprowadzenia specyfikacji chronionego dostępu w C++. Przykład byłby pomocny.Uzasadnienie wprowadzenia specyfikacji chronionego dostępu

+1

Uzasadnieniem wydaje się być "musimy zrobić coś, aby język był bardziej skomplikowany, niż jest potrzebny i bardziej delikatny niż powinien być, aby konsultanci mogli pobierać ogromne opłaty za złą pracę". –

Odpowiedz

2

Poziom dostępu protected jest używany, gdy zajęcia muszą współdziałać z ich spadkobiercami.

Na przykład wyobraź sobie abstrakcyjną klasę Shape, która może zgłosić jej obszar do świata zewnętrznego.

Różne kształty, takie jak trójkąty, kwadraty i okręgi, są różnie opisane (kąt, bok, promień) i inaczej obliczyć ich powierzchnie.

Klasa Shape może mieć publiczną metodę getArea(), która zwraca prywatną zmienną trzymającą ten obszar.
Najlepszym sposobem na ustawienie tej zmiennej byłaby metoda protected o nazwie setArea(double), która byłaby wywoływana przez klasy potomne.

Zatem Circle nazwałbym setArea(PI * radius * radius), Square nazwałbym setArea(side * side) itd

pamiętać, że nie zawsze jest to dobry projekt (ale jest to świetny przykład protected)

+1

Najlepszym sposobem byłoby prawdopodobnie użycie wirtualnej metody "getArea". –

+0

@Matthieu: Tak, ale oznaczałoby to ponowne obliczenie obszaru za każdym razem, gdy zostanie wywołany. – SLaks

+2

Niekoniecznie, to zależy od formy pochodnej, aby zdecydować, czy warto buforować wynik. –

3

Dla tego rodzaju pytania, polecam Projekt i ewolucja C++ przez Bjarne Stroustrup. Sekcja 13.9 opisuje ewolucję chronionych członków.

Krótko po wydaniu 1.0 [z Cfront], Mark Linton zatrzymany przez mojego biura i dokonał zarzutu pasji do trzeciego poziomu kontroli dostępu [...] Twierdził przekonująco na podstawie autentycznego doświadczenia i przykłady z prawdziwego kodu że chronione dane były niezbędne do zaprojektowania wydajnego i rozszerzalnego zestawu narzędzi systemu Windows. [...] To były dobre argumenty, a przede wszystkim te, które przekonały mnie, że pozwolę członkom chronionym. [...]

Pięć lat lub później, Mark zakazała stosowania chronionych członków danych w Wywiady [X okna Toolkit wspomniano wcześniej], ponieważ stał się źródłem błędów. [...] Poważnie komplikują także konserwację [...]

Chronione elementy zostały wprowadzone do wersji 1.2. Zabezpieczone klasy bazowe zostały po raz pierwszy opisane w wydaniu 2.1. Z perspektywy czasu uważam, że protected jest przypadkiem, w którym "dobre argumenty" i moda pokonały moją lepszą ocenę i moje reguły dotyczące akceptowania nowych funkcji.

+2

Nie mogłem się zgodzić, więcej chronionych członków danych stanowi naruszenie hermetyzacji. Używam tylko chronionych metod. –

+0

@Matt: Moim zdaniem, pola w klasach powinny zawsze być domyślnie prywatne, bez mechanizmów, które temu zapobiegną, ponieważ zarówno publiczne, jak i chronione pola przerywają enkapsulację. – fredoverflow

+1

Mam tutaj tę samą opinię.Nie możesz wymusić niezmienności klasy, jeśli ujawnisz swoich członków danych. –

Powiązane problemy