Czy odbicie jest niekorzystne, ponieważ zmiennych prywatnych nie można ograniczyć?

privateModyfikator jest stosowany w celu ograniczenia dostępu spoza klasy, ale przy użyciu odbicia inne klasy mogą uzyskać dostęp do metody prywatny i pola. Zastanawiam się więc, w jaki sposób możemy ograniczyć dostępność, jeśli jest to częścią wymogu.

Modyfikatory dostępu mają na celu informowanie programistów piszących kod o tym, jaki jest publiczny interfejs klasy. Nie są w żaden sposób środkiem bezpieczeństwa i nie dosłownie ukrywają ani nie zabezpieczają żadnych informacji.

Aby zacytować Herb Sutter na temat praw dostępu do klasy :

„Chodzi tutaj o ochronę przed Murphym vs. ochronę przed Machiavellim ... to znaczy ochronę przed przypadkowym niewłaściwym użyciem (co język robi bardzo dobrze) w porównaniu z celowym nadużyciem (co jest faktycznie niemożliwe). programista tak bardzo chce obalić system, znajdzie sposób „

Nie, to faktycznie ważna zaleta. To, że niektórzy programiści nie uważali, że ktoś będzie potrzebował dostępu do jakiegoś stanu wewnętrznego, nie oznacza, że ​​nigdy nie pojawi się żaden uzasadniony przypadek użycia. W takich przypadkach użycie Refleksji do wykonania operacji na obiekcie może być ostatecznością. Musiałem użyć tej techniki więcej niż raz.

Jeszcze bardziej ograniczasz dostępność, wchodząc o jeszcze jeden poziom: środowisko wykonawcze.

Nie wszystkie języki mają tę koncepcję, ale przynajmniej w Javie możesz użyć menedżera bezpieczeństwa, który zabrania udostępniania prywatnych pól. Możesz ręcznie zainstalować menedżera bezpieczeństwa w czasie wykonywania lub dodać zasadę bezpieczeństwa do pliku jar, który jest następnie zapieczętowany, aby zapobiec modyfikacji.

Więcej informacji o tym w Java: Reflection Security

O jakim odbiciu mówisz?

W wielu systemach refleksji obchodzenie enkapsulacji jest jawną możliwością, którą twój kod musi uzyskać i nie ma jej domyślnie.

Jeśli martwisz się o enkapsulację, prostym rozwiązaniem jest po prostu nie używanie systemu odbicia, który go nie chroni.

W Pythonie nie ma modyfikatorów dostępu. Konwencja polega na poprzedzeniu znakiem podkreślenia metod i zmiennych, do których nie oczekuje się dostępu z zewnątrz klasy. Czy to technicznie uniemożliwia ci dostęp do takiego pola z klasy innej firmy? Ani trochę; ale jeśli to zrobisz, jesteś sam i ryzykujesz zepsucie czegoś, bez możliwości obwiniania drugiej klasy.

W języku C # istnieją modyfikatory dostępu, ale są one jeszcze tylko konwencją - wymuszoną przez kompilator, ale nadal konwencją. Oznacza to, że technicznie nadal można uzyskać dostęp do zmiennych prywatnych i zmieniać je, albo poprzez odbicie, albo bezpośrednio manipulując pamięcią (jak robią to trenerzy gier ). Konsekwencja jest dokładnie taka sama: jeśli zmienne w twojej klasie zostaną zmienione przez Odbicie od innej klasy lub przez manipulowanie pamięcią przez inną aplikację, i to psuje coś w twojej klasie, to nie twoja wina.

Pamiętaj, że to oczywiście stwarza problemy bezpieczeństwa, w których strona trzecia może uzyskać dostęp do twoich danych; coś, co prowadzi do zaszyfrowanych wariantów ciągu i podobnych struktur danych. Ale ochrona twojego kodu przed takim użyciem jest bardziej związana z ograniczeniami systemu operacyjnego i dostępu na poziomie kodu i nie ma nic wspólnego z Reflection per se.