Taka ciekawostka.. Zauważyłem, że część osób z branży (od juniorów po seniorów) nie jest świadoma, że modyfikator pola private wcale nie oznacza, że tylko obiekt-właściciel ma do niego dostęp. Inny obiekt tej samej klasy również może odczytać to pole. Wyczytałem to w książce od Javy i byłem zaskoczony. :) A tu przykład w PHP:
<?php
class Test
{
private $someField = 'Hello World';
public function foo(Test $bar)
{
return $bar->someField;
}
}
$testA = new Test();
$testB = new Test();
echo $testA->foo($testB);
W większości języków private zapewnia hermetyzację w ramach klasy a nie obiektu. Dlatego Scala ma private hermetyzujące w ramach klasy i private[this] hermetyzujące w ramach pojedynczego obiektu
@part private nie służy i nie miało służyć do zabezpieczania pól/funkcji przed nieuprawnionym dostępem. To jest po prostu środek do modularyzacji kodu - wskazujemy z czego zalecamy (public) a z czego nie zalecamy (private) korzystać na zewnątrz. Chociaż w javie, jeśli mamy security managera włączonego to private daje rade jako zabezpieczenie (albo raczej powinien), ale to raczej nieczęsto używane jest (sandboxy, typu applety, z tego korzystały).
Pascal to dopiero ma wywalone na private – ani nie blokuje w ramach obiektu, ani nawet klasy. Można się do prywatnego pola dostać nawet z poziomu klasy nie mającej nic wspólnego z tą hakowaną (pod warunkiem, że zadeklarowana jest w tym samym module). Pozory prywatności zachowane. Natomiast do ukrywania wymyślili strict private i strict protected.
Ciekawe czy podobne rzeczy w którymś języku dzielą publiczne elementy. ;)
privatew większości języków to tylko flaga dla kompilatora. Co za problem zgwałcić oop przy pomocy refleksji. Zresztą twój przykład to nic, przy tym po widziałem w C++#define private public