W sytuacji, gdy nick jest używany WYŁĄCZNIE jeśli alias nie istnieje to problemu nie ma. Ale jeśli istnieje alias, a potrzebuje wartość pola nick może się zdarzyć wypadek.
Wersja do druku
W sytuacji, gdy nick jest używany WYŁĄCZNIE jeśli alias nie istnieje to problemu nie ma. Ale jeśli istnieje alias, a potrzebuje wartość pola nick może się zdarzyć wypadek.
Jakiego rodzaju? :)
Jeśli potrzebujesz wartość pola nick po tym gdy do systemu są wprowadzone te całe aliasy, to prawdopodobnie tylko w paru miejscach i tam faktycznie należy zmienić implementację ( np dodać getOriginalNickname() ), właśnie dlatego że tutaj logika biznesowa się zmieniła - w tych miejscach z pobierz nick użytkownika logika zmienia się na pobierz pierwszy nick użytkownika jaki kiedykolwiek miał, co jak najbardizej usprawiedliwia zmianę wykorzystania implementacji. ;)
Tylko jak mówiłem, realistycznie patrząc, takich zmian będzie conajwyżej parę w całym kodzie ( np u mnie były tylko trzy na cały projekt, zmieniliśmy getter na właśnie taki jak wyżej podałem ) a reszta sobie działała na nowej implementacji pobierania nicku. Profit ;)
Nawet raz zapomnisz zmienia powiedzmy. Albo ktoś nowy nie ogarnie tego cyrku, w końcu ciężko sprawdzać implementację każdego gettera. No bo co może robić metoda getNick(). A akurat nowy się spieszy, bo deadline blisko, nie zrobi testu z aliasem i buba. Jasne, że świat się nie zawali w tym wypadku, ale na pewno nie jest to rozwiązanie idealne.
Jak to co? Zwracać nick który jest używany w systemie :) Ty myślisz o tym w kategorii obiektu, a ja myślę w ramach implementacji. To teraz zastanowmy się co jest lepsze? Moje spojrzenie jest takie, że getNick() ma mi zwrócić nick w znaczeniu tego, co widzisz na stronie, i tak naprawdę chuj mnie interesuje jak to działa ( prywatne pole czy jakaś szalona magia ). Twoim zdaniem jak jest getNick() to ma zwracać pole. A na stronie pokazuje się coś innego, kurczę, ciekawe dlaczego? A , bo są jakieś aliasy. I nagle okazuje się że getNick() tak naprawdę nie zwraca nicku :)))
To dalej nie ma sensu. Z czasem się przestawisz , ręczę ;p naprawdę polecam przestać myśleć o obiektach jako o ich wewnętrznym stanie a o jako implementacji interfejsu i starania się separować odpowiedzialność, bo jeśli nie, zaczyna się burdel.
Enough said, dobranoc ;d
Dziękuję wszystkim za rozjaśnienie sytuacji. Choć programowanie obiektowe wciąż jest dla mnie lekką abstrakcją i nie wyobrażam sobie bym go używał w praktyce (no cóż, w tej chwili w głowie mi siedzą malutkie kody typu 'hello world') to przynajmniej natrafiając na nie w czyimś kodzie nie wywalą oczu a ogarnę co tam się dzieje
Nauczysz się wszystkiego z czasem. Wszystko nabierze większego sensu, kiedy dostaniesz tak skonstruowane zadanie że sam uznasz, że stworzenie klasy będzie najlepszym rozwiązaniem :P