To będzie króciutki wpis, niemniej traktujący o dość istotniej zasadzie programowania obiektowego, tj. zasadzie jednolitego dostępu. Jej treść brzmi następująco:

Wszystkie usługi oferowane przez moduł powinny być dostępne za pośrednictwem jednolitej notacji, która nie zdradza, czy zostały one zaimplementowane z wykorzystaniem danych przechowywanych statycznie, czy też obliczanych na bieżąco w razie potrzeby. [Meyer, str. 90]

Jakie są zalety ze stosowania tej zasady? Otóż ułatwia ona hermetyzację klas, sposób implementacji danej cechy klasy może być dowolny i może zmieniać się z czasem, niemniej nie będzie to wymagało jakichkolwiek zmian w kodzie wykorzystującym tę klasę.

Czy środowisko .NET stosuje się do tej zasady? Zapewne nikt nie ma tutaj wątpliwości. Realizują ją właściwości, które mogą albo zwracać wartość przechowywaną w polu, albo uzyskiwać i ustalać ją za pomocą stosownych przekształceń. Jak widać nie wzięły się one znikąd, ale za ich powstanie odpowiada konkretna zasada.

Warto jeszcze wspomnieć, że właściwości nie są jedynie domeną .NET, o wiele wcześniej były one dostępne w Visual Basic czy Delphi. Także Eifel, język stworzony przez cytowanego tutaj Betranda Meyera ma je w swojej składni (a jakże by inaczej 😉 ). Co ciekawe w Delphi, gdzie wywołanie funkcji bezparametrowej – przeciwnie niż w C# – nie wymaga podawania nawiasów, taki zapis jest tożsamy z pobraniem wartości za pomocą właściwości:

kolor.wartosc; // nie wiadomo czy to metoda czy właściwość

takie zachowanie języka sprawia, że zmiana metody na właściwość nie wymaga refaktoryzacji kodu, który korzystał ze zrefaktoryzowanego obecnie obiektu. Oczywiście ma to zastosowanie jedynie w przypadku odczytu, ponieważ dla zapisu metoda wymaga już podania parametru i tu refaktoryzacja będzie niezbędna.

kolor.wartosc(zielony); // tu, bez wątpienia, jest wywołanie metody