Nie znam podstaw - uświadamiam sobie...

Witam aplikuje od jakiegoś czasu na juniora Java, pisałem aplikacje webowe - używałem Springa MVC, Hibernate i tworzyłem ogólnie takie własne projekciki. po pierwszych rozmowach uświadamiam sobie że nie umiem nawet podstaw teoretycznych z JAVY SE...

W efekcie nie mam szans przejść rozmów kwalifikacyjnych - wniosek: zrobiłem źle rzucając się na "wyższe" technologie nie znając bardzo dobrze JAVY standard. Pozostaje tylko teraz wracać się do korzeni i ryć na pamięć teorię ??

troche sie zalamalem przyznam...

solutryp napisał(a):

Pozostaje tylko teraz wracać się do korzeni i ryć na pamięć teorię ??

Jeżeli dla ciebie nauka języka programowania to "rycie na pamięć teorii" to może zastanów się nad innym zawodem, bo takie podejście świadczy tylko o tym, że robisz to z dużą niechęcią.. W przyszłości szybko się wypalisz

Nie o to chodzi lubię rozwiązywać problemy w praktyce programując, ale nie znoszę jak muszę się np. nauczyć na pamięć czegoś co potem muszę wyrecytować na rozmowie a normalnie robiąc projekty po prostu zerkam w dokumetację.

A co takiego cię pytali, że nie wiedziałeś?

Ale jak to mozliwe, ze napisales jakis webserwis nie znajac podstaw jezyka?

Swoja droga to jakim cudem uzywales (o ile to nie bylo tylko kopiuj wklej) springa, hibernate'a i itp nie znajac podstaw ? Cos krecisz albo przesadzasz.

Np. trywialne pytanie o rozpisanie / rozrysowanie interejsow/implementacji kolekcji + wady + zalety. Normalnie to otwieram doca i jazda a tak to po prostu takich rzeczy w 100% nie pamiętam..

ale to jest na prawdę przydatne i w pracy etatowej będziesz miał z tym styczność tak samo często jak z webserwisami... Zapewniam Cię, nie jest to żadna teoria.

Inne pytanie.
Jak to mozliwe, ze napisales webserwis nie znajac podstaw struktury biblioteki kolekcji?

Zgaduje że napisałeś w tych technologiach jakiegoś prostego cruda bez backendu i stąd problem. A nazywania takich rzeczy teorią i pisanie o ryciu na pamięć to nawet nie skomentuje.
Ktoś podrzuci linka do pana seligi? :-)

nie, bo film Pana Seligi nie ma zbyt wiele wspólnego z rzeczywistością, która otacza 90% programistów

W sensie te 90% to klepacze 8-tysiecznikow? Tak, masz racje.

Dziwi mnie, że napisałeś o "ryciu na pamięć" (rozumiem, że przyswajanie tej wiedzy nie jest w twoim top ten ulubionych zajęć :D). Piszę ostatnio projekt w którym bardzo intensywnie wykorzystuje kolekcje i mam do tego zupełnie inne podejście. Użycie odpowiedniej kolekcji zmienia i upraszcza architekturę programu w tylu przypadkach, że byś się zdziwił, ergo -warto/trzeba/wypada je znać. Poza tym, abstrahując już od kolekcji, bo rozumiem, że to tylko przykład, jeżeli w trakcie klepania zorientuję się, że jakiś element mogłem zaprojektować lepiej z użyciem jakiejśtam biblioteki to uważam to za swój sukces, bo zdobyłem wiedzę na przyszłość i będę potrafił się do tej wiedzy odnieść w rozmowie (chyba nie kazali ci wymienić wszystkich metod interfejsu XXX :P) Reasumując - to co ludzie napisali wyżej- jeżeli dołuje cię sama myśl o przeczytaniu 30 stron o kolekcjach, to po co się męczyć? Lepiej robić coś co się lubi.

Zawsze jest sposób na to żeby kogoś zagiąć.
W programowaniu najłatwiej bo masz odpowiedź typu wiem/nie wiem.
W bardziej życiowych tematach (jak np. pensja) można lawirować.

Ja pamiętam moją rekrutację na programistę C#. W zadaniu rzuciłem wyjątek w konstruktorze i wielkie halo, że tak się nie robi. No to ja tłumaczę, że jest odśmiecacz pamięci oraz try-catch. Nie zrozumieli tego i zostałem odrzucony.

Albo ty nie zrozumiales, ze w konstruktorze sie nie rzuca wyjatkami.

n0name_l napisał(a):

Albo ty nie zrozumiales, ze w konstruktorze sie nie rzuca wyjatkami.

Ja myślę, że wyjątki należy rzucać na możliwie najniższym poziomie, żeby potem nie męczyć się z debuggowaniem.

A co to ma konkretnie do konstruktorow?

n0name_l napisał(a):

A co to ma konkretnie do konstruktorow?

Jak konstruktor przyjmuje parametr, to w przypadku błędu rzuca wyjątek.
Gdy nie rzucisz wyjątku w konstruktorze, to musisz go rzucić gdzieś wyżej w przypadku błędu.

**Always remember the "Fail Early Principle". Concept being fail now, so you don't waste time debugging or experience unexpected system functionality.

Throwing it in the constructor is fine - there are several classes in the .NET framework that do this. **

Do walidowania parametrow w ogole wyjatki nie powinny byc uzywane... Conajwyzej mozna jakies asercje tam wsadzic, ale tymbardziej nie tak, zeby ktos to obslugiwal, tylko zeby zostalo w logach, ze cos wyzej nie dziala.

A co do tej zasady, to z tego co rozumiem, to nalezy rzucac wyjatki mozliwie jak najwczesniej, czyli absolutnie nie na najnizszym poziomie..

n0name_l napisał(a):

A co do tej zasady, to z tego co rozumiem, to nalezy rzucac wyjatki mozliwie jak najwczesniej, czyli absolutnie nie na najnizszym poziomie..

Zgadzam się, że jak najwcześniej.

To co jest wcześniej wykonane? Utworzenie obiektu czy operacje na nim?

To co jest wcześniej wykonane?

Pobranie danych do utworzenia do tego obiektu.

Nie znam podstaw - uświadamiam sobie...

n0name_l napisał(a):

To co jest wcześniej wykonane?

Pobranie danych do utworzenia do tego obiektu.

A jak moim zadaniem jest utworzenie tylko tej klasy i jej konstruktora z parametrami? Olać sprawdzanie i niech sobie sprawdza ten co będzie jej używał?

Nie rozumiem zbytnio pytania.

Nie powinienem rzucać wyjątków w konstruktorze tylko tam, gdzie są przekazywane do niego argumenty. Czyli sprawdzanie danych ten kto pisze konstruktor olewa i niech robi to ten co będzie używał tego.

Tak.

n0name_l napisał(a):

Tak.

Rozumiem.

Ewentualnie:

public Class1(SomeType param1)
{
    if (param1 == null)
        MessageBox.Show("Ten co używa tej klasy to idiota i nie sprawdza co przekazuje do konstruktora.");
    Application.Exit();
}

myśliwy napisał(a):

Ja pamiętam moją rekrutację na programistę C#. W zadaniu rzuciłem wyjątek w konstruktorze i wielkie halo, że tak się nie robi. No to ja tłumaczę, że jest odśmiecacz pamięci oraz try-catch. Nie zrozumieli tego i zostałem odrzucony.

Odśmiecacz i try-catch nie mają nic do rzeczy. Konstruktor musi się wykonać szybko i niezawodnie, jak int x = 7, dlatego nie rzuca się w nim wyjątków, nie przeprowadza operacji I/O, nie deserializuje, nie generuje miliona losowych liczb, itd. Jeśli takie operacje są potrzebne do utworzenia obiektu, to pisze się statyczną metodę fabrykującą w danej klasie.

Nie widze niczego zlego w rzucaniu wyjatkow z konstruktora, i znam bardzo duzo przykladow gdzie tak jest to robione. Prezentacje pana Religi widzialem i uwazam kolesia za kompletna pomylke, ale to tylko ja.

mućka napisał(a):

Nie widze niczego zlego w rzucaniu wyjatkow z konstruktora, i znam bardzo duzo przykladow gdzie tak jest to robione.

Nawet na stackoverflow ludzie napisali, że tak jest OK, tylko, żeby zasoby były zarządzane, bo niezarządzane zasoby mogą spowodować wycieki pamięci.

Jeden post jest nawet o tym, że sam .NET Framework ma klasy, które rzucają wyjątek w konstrukturze.