🚀 go-pugleaf

Witam

Piotr Kobzda wrote:

> to nikt mi z zewnątrz nie popsuje obiektu tak:
> 
>      MyClass obj = new MyClass();
>      obj.myData = null;

Piotrze nie przesadzaj. W C++ tak też się nie da. Pan A.K. zrobił o wiele
więcej. zrobił cos co trudno się robi w Javie. Tak więc to nie jest żadne
potrówanie.

To co napisałeś w C++ też nie przejdzie, dostaniesz w czasie kompilacji
błąd, że próbujesz grzebać w sekcji prywatnej.
 
> czy tak:
> 
>      Filed f = MyClass.class.getDeclaredField("myData");
>      f.setAccessible(true);
>      f.set(obj, null);

A to?

> Nawet jeśli uda mu się to skompilować.
> 
> Żadnych PIMPLów, czy jak im tam, nie potrzeba.

PIMPL woją drogą jest dobry (używany nie wprost), jak udostępniasz
interfejs. PIMPL oznacza "Private implementation", tak więc rozszerzając
ideę np. pisząc gettery i settery właśnie robisz pimpla, tylko tego tak nie
nazywasz.

 
>> PS: Co nie zmianai faktu ze PIMPL to nie jakis antidotum
>>        _likwidujace_ bezpieczenstwo.
>>       On tylko je pomniejsza.
> 
> Tu zakładam, że mówisz o *nie*bezpieczeństwie, inaczej to PIMPL raczej
> odradzać trzeba...  ;)

Pamiętaj, że PIMPL to nie tylko bezpieczeństwo. 

Zobacz na header, który pokazałem. Zobacz, że ja mogę całą masę rzeczy robić
pod spodem, Ty masz cały czas ten sam header. Mogę dostarczyć Ci
skompilowany kod i nie ma problemu. Twój kod nadal używa starego headeru,
nawet jeśli jak wymieniłem wszystko pod spodem. 
Podsumowując. PIMPL służy też do robienia niezależnych ubgrade
poszczególnych części kodu bez konfliktów. Chyba że zmiany są na tyle duże
że dotyczą interfejsu publicznego, ale wtedy nie ma rady.

Pozdrawiam. 

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/