adamk : Jeszcze bardziej private

Jeszcze bardziej private

Trackback 12 maja 2010 o godzinie 08:25:37 w Ogólne,Techblog

W językach obiektowych opartych o składnie nawiasów klamrowych (C++, C#, Java, ...) mamy zasadniczo trzy możliwości regulowania dostępu do składników klasy: private, protected oraz public. Niektóre języki dorzucają jeszcze inne (np. internal w C#), ale te trzy to podstawa.

Dla przypomnienia: public to elelment klasy dostępny dla wszystkich, także spoza klasy. Private to element prywatny, dostępny tylko w klasie, a protected to prawie to samo co private, z tym że jest dostępny dla klas pochodnych.

Mam propozycję, aby dodać jeszcze jeden regulator w tym zakresie.

Pisząc kawałek kodu zdałem sobie sprawę, że przydatna może być deklaracja, która ogranicza dostęp do elementu klasy, tylko do konkretnego obiektu - tzn. tylko obiekt A (i jego metody) mogą uzyskać dostęp do tak zadeklarowanego elementu A.a. Inne obiekty tej samej klasy, nie mogą uzyskać takiego dostępu. Taki instance-private.

Zalety takiego rozwiązania, to dodatkowy stopień hermetyzacji oraz potencjalne możliwości optymalizacji kodu dla kompilatora, oparte o dokładnej wiedzy kiedy następuje dostęp do składnika klasy.

Jakie są wasz opinie? A może są języki które mają tego typu mechanizm, o których nie wiem?

Powrót do reszty wpisów

Komentarze

12 maja 2010, 09:51:09

matekm

IMO, takie instance-private zbytnio komplikowałoby czytanie kody przez kogoś kto go nie pisał. Trzeba by było określać, które instancje mają dostęp do danych pól a które nie.

Dodatkowo, godzi to w całe podejście OOP - obiekty tej samej klasy powinny mieć te same właściwości. Chcesz coś o innych właściwościach - powinieneś stworzyć nową klasę.

12 maja 2010, 09:52:29

AdamK

Dlaczego godzi w podejście OOP? Obiekty tej samej klasy miałyby te same właściwości, ale niedostępne dla innych obiektów tej samej klasy.

12 maja 2010, 09:57:47

AdamK

Może napiszę skąd mi to wyszło: w C# mamy możliwość napisania get/set dla pola w klasie. Często używa się tego tak:

private string _pole;

public string Pole
{
get { rerurn _pole; }
set { _pole = value; }
}

To oczywiście uproszczony przykład, bo chodzi o to get/set Pole jest jakiś dodatkowy kod który uprawia jakąś dodatkową magię przy dostępie do tego pola. W takim układzie, bardzo często _pole nie powinno być widoczne dla absolutnie nikogo, poza swoją instancją obiektu.

12 maja 2010, 10:07:13

foobar

No, w Javie jest jeszcze dostęp pakietowy.

12 maja 2010, 10:57:10

Hoppke

To prawda. Ale ze problem wystepuje tylko w przypadku dobierania sie do detali obiektu z poziomu innej instancji tego samego typu...

W praktyce rzadko widuje obiekty typu FOO probujace operowac na obiektach typu FOO... i najczesciej sa to jakies metody pomocnicze dolepione do prostych obiektow danych, np. String i jakies String.replace(String, String), czy Integer.add(Integer)

A gdy juz do tego dochodzi, to nie ma wiekszego problemu z izolacja -- wszystko zamyka sie w pojedynczym typie, wiec autor jest jeden i kawalek kodu tez jeden (jesli Integer ma jakies pola prywatne ktore sa wrazliwe, to dostep do nich bedzie mial jedynie kod zawarty w klasie Integer. Poniewaz to ta sama klasa, to widzisz caly kod, lacznie z np. metodami dostepowymi. Tworca i konsument sa jedna i ta sama osoba -- nie potrafie sobie wyobrazic programisty, ktory by tu cos potrafil skopac...)

I wydaje mi sie, ze kompilator i tak wie doskonale o wszystkich odwolaniach do prywatnych pol -- o ile jezyk nie pozwala na modyfikowanie klas/typow "at runtime", to wszystkie potencjalne "dostepy zewnetrzne" mozna wykryc parsujac kod klasy, bo ma gwarancje, ze po kompilacji nie pojawia sie juz zadne nowe kawalki kodu majace dostep do pol prywatnych...

Hermetyzacja jest fajna, ale potrzeba ukrywania fragmentow klasy przed innymi fragmentami to juz IMO wskazowka, ze klasa ma zbyt duza odpowiedzialnosc ("robi zbyt wiele"), i jej funkcjonalnosc powinna zostac rozdzielona do osobnych klas (lub w inny sposob przeprojektowana).

Jesli musisz chronic klase przed nia sama, to... coz, nie brzmi to najlepiej, no nie?

12 maja 2010, 11:02:14

AdamK

To mi się naszło przy pisaniu metod kopiujących. Jeśli autor jest jeden to zazwyczaj jest to ok, ale jak wielu, to można przeoczyć fakt że nie powinno się używać _pola innego obiektu nawet wewnątrz klasy, ale zawsze Pola. To może być źródło brzydkich i trudnych do znalezienia błędów.

Kompilator, owszem wie, ale jak się mu podpowie to wie lepiej :). Oczywiście, "at runtime" można zrobić (prawie) wszystko, np. w C++ przez wskaźnik można zmodyfikować rzeczy zadeklarowane jako const. To już jest jednak wprost błąd i zachowanie niezdefiniowane, no i wymaga pewnej gimnastyki.

12 maja 2010, 11:27:40

Hoppke

OK. "instance-private" troche by tu pomogl, ale byloby to IMO leczenie objawow. Bo problemem wydaje sie tu byc raczej nadmiernie rozrosnieta/zamotana klasa, lub brak dobrych nawykow u programistow, a nie sama kontrola widocznosci.

W przypadku C#/javy niezlym rozwiazaniem mogloby byc wsparcie w IDE i inteligentne odfiltrowywanie pol w mechanizmach dopelniania. Do kopiowania/inicjalizowania obiektow pewnie sa juz jakies pluginy generujace kod, lub biblioteki pomocnicze... Rozwiazanie problemu u zrodel, w skladni jezyka wydaje sie byc bardziej intuicyjne i sluszne z punktu widzenia inzyniera, ale czy chcialbym uzywac jezyka ktory ma "keyword na kazda okazje"?

A, tak w ogole dobrym wyjsciem moze byc uabstrakcyjnienie typu przez wydzielenie API dostepowego do osobnego typu (interfejsu), i uzywanie wszedzie tego typu-interfejsu zamiast deklarowania konkretnej implementacji. Czyli np. String bylby implementacja dla CharContent, a String.replace(String, String) zamienialoby sie w String.(CharContent, CharContent)

Troche armata na wroble w tym przypadku, ale ogolnie to niezla i sluszna praktyka, wystawianie typu-API zamiast typu-implementacji.

12 maja 2010, 11:41:05

AdamK

Inerfejs to dobra rzecz, ale to raczej przy dziedziczeniu. Taki instance-private to przydałby się na etapie implementacji i utrzymywania. Trochę analogicznie do systemów rozproszonych, gdzie może działać wiele instancji serwera, które mimo że należą do tej samej 'klasy' to w garnki sobie wzajemnie nie zaglądają.

12 maja 2010, 12:14:18

Hoppke

Zalezy co rozumiesz przez "dziedziczenie"... Czesto uzywam interfejsow nawet jesli mam dla nich tylko jedna konkretna implementacje -- niektorzy tego nie lubia (moge zrozumiec tych, ktorzy przeszli np. pieklo EJB), ale to bardzo ulatwia pewne rzeczy, jak np. hermetyzacje.

Osobiscie mysle o nich troche jak o plikach naglowkowych -- oderwanie implementacji od API. Jak np. we wzorcu fabryki.

12 maja 2010, 12:37:58

matekm

"W takim układzie, bardzo często _pole nie powinno być widoczne dla absolutnie nikogo, poza swoją instancją obiektu"

A jest widoczne? ja Cię chyba nie rozumiem: pola "private" widoczne są tylko dla danego obiektu, jo? Poka jakiś przykład wyjaśniający o co tobie chodzi;>

12 maja 2010, 12:40:31

AdamK

private powoduje że dany element klasy nie jest widoczny poza nią, ale jest widoczny pomiędzy obiektami. Jeżeli mamy obiekty A i B, i metodę w ich klasie której parametrem jest obiekt tej klasy, to przy (wywołanie w stylu A.metoda(B)) to jeden obiekt może zmodyfikować elementy private drugiego.

12 maja 2010, 12:53:17

matekm

mógłbyś podać realny przykład, bo to chyba wykracza poza moją wiedzę;)

12 maja 2010, 12:53:46

matekm

w sensie kawałek kodu demonstrujący to o co Tobie chodzi:)

12 maja 2010, 12:55:33

AdamK

Chodzi mi o taką sytuację:

class A
{
private int i;

public void metoda(A a)
{
a.i = 1;
}
}

Obiekt klasy A modyfikuje pole prywatne innego obiektu tej samej klasy.

12 maja 2010, 13:14:37

Hoppke

No i tu pojawia sie pytanie -- czy definiowanie prywatnych kontraktow "wewnatrz" klasy to cos, co jest naprawde potrzebne? (jesli traktujemy modyfikatory widocznosci jako narzedzie do tworzenia kontraktow)

12 maja 2010, 13:21:56

mt3o

Jeśli masz problem z ludźmi używającymi zmiennej prywatnej zamiast settera, wymuszaj na grupie stosowanie niewygodnych i nic nie mowiących nazw zmiennych tak, aby stosowanie ich zamiast getterów i setterów stało się niewygodne ;) Objaw leczony objawem, bez ingerencji w strukturę języka programowania.

12 maja 2010, 16:20:52

Hoppke

Nie no, to, ze ktos robi burdel nawet w ramach pojedynczego pliku zrodlowego to jeszcze nie powod, zeby swoj wlasny kod "obfuskowac".

Inna sprawa, ze jesli komus sie nie chce obejrzec metod dostepowych nawet jesli sa w tym samym pliku, ktory delikwent edytuje, to chyba nic nie pomoze. Poza wzieciem delikwenta na bok i wyjasnieniem co zrobil zle i dlaczego ma tego wiecej nie robic.

12 maja 2010, 16:25:31

AdamK

Metody jednej klasy niekoniecznie muszą siedzieć w jednym pliku.

12 maja 2010, 16:59:41

Hoppke

Jesli to stanowi jakas roznice dla tych programistow, to moze lepiej trzymac klasy w pojedynczych plikach?

12 maja 2010, 22:18:21

Tomasz Wysocki

W C++ można to uzyskać za pomocą makr. Nie jest to może rozwiązanie, które kompletnie uniemożliwia dostępu do zmiennej, jednak gdyby ktoś był na tyle uparty, żeby się przez to przedzierać, to wbudowany w język operator, też by nie pomógł (przecież można by go zmienić).

Z drugiej strony w ten sam sposób jest robione "private" w Pythonie.

Moja implementacja (mizerna, bo w C++ nie programuje, a tym bardziej w makrach preprocesora (-: ):
#define ZACIEMNIACZ nitk_nie_bedzie_wpisywal_tak_dlugiej_zmiennej
#define localVar(a) ZACIEMNIACZ##_##a
#define local(a) this->ZACIEMNIACZ##_##a
#undef ZACIEMNIACZ

class X {
int localVar(xyz);

void test() {
local(xyz) = 1;
}
};

Wysyłając komentarz wyrażasz zgodę na jego publikację na zasadach licencji . Jeżeli się na to nie zgadzasz, nie komentuj.

Jeszcze bardziej private

Komentarze

Archiwum

Kategorie

Linki