Pytania rekrutacyjne 馃か [MID] – Prymitywy-Wrappery-Obiekty 馃し鈥嶁檪锔忊潛

Hej. By艂em ostatnio na rozmowie rekrutacyjnej i my艣l臋, 偶e warto podzieli膰 si臋 tu moim do艣wiadczeniem. Na pocz膮tku zaznacz臋, 偶e by艂a to rozmowa na stanowisko Java Developera – stricte Java – nie pada艂y pytania o frameworki. Rekruterzy skupili si臋 na pytaniach wymuszaj膮cych logiczne my艣lenie (no kto by si臋 spodziewa艂) i dopytywali si臋 o wiedz臋 odno艣nie core’owych element贸w Javy – co, jak i dlaczego. Nawiasem m贸wi膮c bardzo podoba艂 mi si臋 taki styl prowadzenia rekrutacji.

Jeszcze s艂owo odno艣nie nietechnicznych aspekt贸w. Rozmowa by艂a prowadzona przez 2 developer贸w (tech lead贸w) i trwa艂a oko艂o 2 godzin. Zaoferowali mi ca艂kiem fajn膮 ofert臋 ale niestety nie godzili si臋 na prac臋 zdaln膮 w 100% wi臋c si臋 nie dogadali艣my.

Z tej rozmowy na bloga chc臋 przela膰 jedno z ciekawszych pyta艅 jakie pad艂o i jedno zadanie jakie musia艂em wykona膰 robi膮c live-coding (btw. poleg艂em na tym zadaniu bardzo bardzo…). Pytanie opisz臋 w tym artykule a zadanie pojawi si臋 za dwa tygodnie w sobot臋.


Ok… o co chodzi z tym pytaniem? Prymitywy-Wrappery-Obiekty 馃し鈥嶁檪锔忊潛. Mia艂em przedstawiony nast臋puj膮cy kawa艂ek kodu

I dosta艂em pytanie: Co zostanie wypisane na ekranie?

  • a) 12.3
  • b) 0
  • c) 11.3

Pytanie raczej z gatunk贸w proste – btw. zanim przeczytasz dalej, sam na nie odpowiedz (albo napisz w komentarzu, 偶eby da膰 mi satysfakcj臋 偶e nie pisz臋 do 艣ciany). Szybka analiza kodu i wiedza, 偶e Java dzia艂a pass-by-value daje nam oczywi艣cie odpowied藕 a) 12.3.

A teraz pytanie co si臋 stanie jak kod zmienimy w nast臋puj膮cy spos贸b? (zmiana prymityw贸w na Double)

Java dzia艂a pass-by-value ale je偶eli przesy艂amy obiekt i modyfikujemy co艣 w nim (najcz臋艣ciej przez settery) to stan obiektu powinien si臋 zmieni膰 nawet po wy艣ciu z metody, tak? To takie troch臋 pytanie retoryczne bo odpowied藕 brzmi TAK. Wi臋c co teraz? Jaka b臋dzie odpowied藕? …. <chwilka na namys艂>. Ponownie prawid艂ow膮 odpowiedzi膮 jest a) 12.3. Dlaczego? Je偶eli nie wiesz (ja si臋 na tym wywali艂em, bo nie wiedzia艂em co tak naprawd臋 robi wrapper double’a) to sp贸jrz na lini臋 3. Nie u偶ywamy tu 偶adnego setter’a do zmiany stanu obiektu, u偶ywamy tylko znaku przypisania =. Ba… wi臋cej. Zajrzyjmy do klasy Double i zobaczmy jakie metody s膮 tu dost臋pne.

Widzisz jakie艣 metody do zmiany stanu wewn臋trznej zmiennej (value)? Raczej nie i nie szukaj bo nie znajdziesz. Wszystkie wrappery zosta艂y celowo zaprojektowane tak aby nie da艂o si臋 zmieni膰 ich stanu wewn臋trznego. Dlaczego? Tak膮 decyzj臋 projektow膮 podj臋艂y osoby, kt贸re to implementowa艂y – nie ma na to jasnej odpowiedzi. Jednym z plus贸w takiego rozwi膮zania jest na pewno to, 偶e mo偶emy dzia艂a膰 bezpiecznie z wieloma w膮tkami dzi臋ki temu, 偶e klasa jest niemutowalna. Wi臋c co tak naprawd臋 si臋 sta艂o, 偶e mimo wszystko przypisanie do zmiennej x, kt贸ra by艂a typu Double zadzia艂a艂o wewn膮trz metody i 偶e po wyj艣ciu z tej metody mieli艣my t臋 sam膮 warto艣膰 co poprzednio? <Dzi臋ki Cepewka> Zadzia艂a艂 tu wcze艣niej wspominany mechanizm pass-by-value i bardzo polecam prze艣ledzi膰 sobie dok艂adnie t膮 odpowied藕 na stackoverflow, kt贸ra fajnie obrazkowo pokazuje dlaczego to dzia艂a w艂a艣nie w ten spos贸b. I nie ma to znaczenia czy prze艣lemy tu obiekt wrapuj膮cy czy jakikolwiek inny. Autoboxing i Unboxing, czyli automatyczna konwersja, kt贸rej dokonuje kompilator Javy dzi臋ki czemu my – developerzy – mamy czystszy kod. Dla bardziej dociekliwych – oto jak wygl膮da byte code metody decrement

To co nas interesuje to linie 1 (unboxing) i linia 6 (autoboxing). Jak widzisz pomimo tego, 偶e wysy艂ali艣my Double’a to jednak kompilator pod spodem robi troch臋 niewidocznej roboty… Nasza warto艣膰 zosta艂a na pocz膮tku skonwertowana do typu prymitywnego (java/lang/Double.doubleValue), nast臋pnie zosta艂a wykonana operacja odejmowania i z powrotem dostajemy klas臋 wrapuj膮c膮 (java/lang/Double.valueOf). My艣l臋, 偶e warto wiedzie膰 takie rzeczy… pr臋dziej lub p贸藕niej (w moim przypadku p贸藕niej :D) :).

Je偶eli chodzi o pytania z rozmowy odno艣nie tego zagadnienia to w艂a艣ciwie na tym si臋 sko艅czy艂o. Po tym jak poleg艂em z brakiem mojej wiedzy o klasach wrapuj膮cych, my艣l臋, 偶e rekruterzy nie do ko艅ca chcieli ci膮gn膮膰 ten wagonik. Jednak wydaje mi si臋, 偶e mog艂oby tu si臋 pojawi膰 pytanie, co zrobi膰, 偶eby m贸c zmodyfikowa膰 stan tego obiektu. I mo偶na tu udzieli膰 dw贸ch odpowiedzi. Pierwsza to oczywi艣cie zwraca膰 warto艣膰 z metody i przypisywa膰 j膮 do nowej zmiennej. Druga opcja to dodanie pola do klasy Decrement przechowuj膮cego warto艣膰 i modyfikowanie tego pola w ramach metody decrement a nast臋pnie odwo艂ywanie si臋 do niego w metodzie wypisuj膮cej wynik na ekran (tylko trzeba pami臋ta膰, 偶e to ju偶 nie jest thread-safe). O co艣 takiego


To na tyle w tym tygodniu :). Dzi臋ki za przeczytanie i standardowo zapraszam za tydzie艅 o 12:00 (sobota), gdzie pojawi si臋 wpis o najbardziej przydatnych (moim zdaniem) skr贸tach klawiszowych do IntelliJ.

0 0 vote
Article Rating
Subscribe
Powiadom o
guest
3 komentarzy
najnowszy
najstarszy oceniany
Inline Feedbacks
View all comments
trackback

[…] Dzi艣 przedstawi臋 Ci temat o kt贸rym wspomina艂em 2 tygodnie temu tutaj聽– czyli zadanie praktyczne jakie dosta艂em na rozmowie […]

Cepewka
Cepewka
3 miesi臋cy temu

To nie ma nic wsp贸lnego z boxingiem lub unboxingiem, jakby艣 zrobi艂 analogiczne zadanie na stringach, to by艂by taki sam efekt: https://ideone.com/G7C1Jg

Tu chodzi o to, 偶e w Javie typy referencyjne s膮 przekazywane przez warto艣膰 referencji (co wielu niepoprawnie nazywa call by reference, a co poprawnie nazywa si臋 call by share).