Zauważyłem, że mam nawyk dodawania przedrostka "get" przed nazwami metod. Jest to zrozumiałe gdy mamy metody setXXX() oraz getXXX() ale dodaje ten prefiks nawet wtedy, gdy nie mam metody setXXX(). Czyli jest np. getUrl() zamiast po prostu url().
Też tak macie? Czy uważacie, że jest to poprawne podejście? A jeżeli nie, to dlaczego?
Funkcja getUrl - mówi mi, że pobrany zostanie adres. Pobrany, a nie wyświetlony, przetworzony, doklejony. Metoda url() - nic mi nie mówi - tym bardziej jeśli działa pod maską jak standardowy getter. Nazewnictwo takie jak url() czy next_post() kojarzą mi się tylko z WordPressem, którego kod moim zdaniem jest mało czytelny i jednoznaczny.
TL:DR - tak - getUrl() to moim zdaniem idealna nazwa.
W Javie taka jest konwencja nazewnicza. Zresztą dodatkowo konwencja mówi że metody powinny określać czynność, więc samo "url" nie spełniałoby tych wymogów.
Ja to też zawsze wiążę z faktem, że metoda "coś robi" - czyli jakiś czasownik by się przydał np deleteComment, processData....
Wzorce getXxx / setXxx / isXxx są zgodne ze standardem nazewnictwa Java Beans.
Ale nie wiem czy to pochodzi akurat z Javy.
Inne wzorce to:
cichy getter i setter
name() - getter
setName(value) - setter
cichy getter i cichy setter
name() - getter
name(value) - setter
cichy getter i brak settera (klasa niemutowalna)
cichy getter i builder w miejscu settera
name() - getter
withName(value) - builder zwracający nowy obiekt klasy na której wywołana jest metoda
Yegor Bugayenko w "Elegant Objects" w tym temacie dość mocno się rozwinął - stwierdza że powinno się unikać prefiksów typu "getXxx" czy "calculateXxx" ponieważ sugerują one sposób realizacji pobrania wartości, co łamie enkapsulację. Wg niego settery oczywiście są też be, zwłaszcza w dobie programowania funkcyjnego.
W czasach Delphi uznawałem, że wystarczy ustalić słownik takich prefiksów żeby było wiadomo co robi dana metoda, przykładowo:
Dzisiaj, po wielu latach pracy w korporacjach, sądzę że nazewnictwo to najczęściej pomijany szczegół w implementacji, ew. służący dezinformacji, w związku z tym cieszę się jak ktoś stosuje chociaż nazewnictwo Java Beans.
jeszcze jest kolejna konwencja - czyli właściwości, które uruchamiają getter/setter pod spodem:
someObject.value // uruchomi się getter z automatu
someObject.value = 123; // uruchomi się setter z automatu
w niektórych językach (np. JS) da się tak robić, ale mam mieszane uczucia. Z jednej strony jest to fajne (choćby przez fakt, że w JS można robić wszystko publiczne, a potem dodać setter/getter później, jak będzie potrzeba), z drugiej strony zaciemnia to kod, nieraz już miałem bugi w programach dlatego, że zewnętrzna biblioteka udostępniała pewne obiekty, które wyglądały jakby wszystko miały publiczne, a tak naprawdę miały jakąś magię pod spodem.
Węc podoba mi się to na poziomie estetyki, cukru składniowego, jednak wolę nie korzystać, żeby nie zaciemniać kodu bez potrzeby.
No i zwykle staram się nie pisać getterów, żeby nie łamać enkapsulacji. Jeśli potrzebuję udostępnić jakąś wartość to często robię to w postaci getXXX, natomiast bez settera w stylu setXXX, bo zwykle się i tak nie przydają, a łamie to enkapsulację, zasadę YAGNI oraz wprowadzania mutowalny stan. To obiekt powinien sam wiedzieć, które zmienne ma ustawić w danej sytuacji, a nie użytkownik (bo para getXXX i setXXX tak naprawdę nie różni się od zrobienia zmiennej publicznej).
Jeszcze teraz ostatnio zacząłem robić samo get, bez nazwy zmiennej, taki ogólny getter, który bierze jako argument stringa i na podstawie tego wydobywa pewne zmienne, np.:
obj.get('something')
obj.get('something.else')
Czyli trochę jak jQuery robi z zapytaniami:
$("#something > input")
fajnie się tak tworzy różne DSLe (chodzi o to, że obiekt może przyjąć stringa, zparsować go choćby wyrażeniem regularnym do tokenów, i potem zanalizować co użytkownik chce i w jaki sposób mu te dane udostępnić). Też nazywam to czasem query a nie get (bo to bardziej jak takie zapytanie do obiektu wygląda).
- cichy getter i cichy setter
name() - getter
name(value) - setter
we frontendzie to się nazywa jQuery style getters and setters :) Jest to fajne dla bibliotek, które zamierzają być przede wszystkim przyjazne userowi, bo to w połączeniu z fluent interface pozwala na dość zwięzłe i deklaratywne pisanie.
$("#some-element").attr('href', 'example.js').text('This is link');
jest to dość cukierkowe programowanie, ale czemu nie. W jQuery się to sprawdziło.
LukeJL napisał(a):
jeszcze jest kolejna konwencja - czyli właściwości, które uruchamiają getter/setter pod spodem:
someObject.value // uruchomi się getter z automatu someObject.value = 123; // uruchomi się setter z automatu
Z tego co wiem robią też tak Delphi i C# (dzięki wspólnym korzeniom oba mają coś takiego jak "property").
Właściwości
Unikanie get/set jest jedną z zasad podejścia znanego jako Object Calisthenics.