Na początek C#...

1

pewnie tematów podobnych jak ten jest na pęczki. Wdrażam się w naukę programowania ze względu na przekwalifikowanie się a także by spełnić swoje marzenia z wczesnej młodości by coś samemu tworzyć i pisać programy. Miałem różne perypetie życiowe, że musiałem brać "byle" jakie prace czy to na słuchawce by dzwonić do klientów po to aby mieć kasę, która w trybie pilnym była mi potrzebna. Nastał czas spokoju w życiu i zamierzam wrócić do planu by nauczyć się programować i również aby moja przyszła rodzina, którą zakładam godnie żyła. Wybrałem język C# do nauki, też ze względu , że pojawiła się możliwość odbycia stażu w pewnej firmie jako junior developer w .NET.

Pytanie czy dla nowicjusza taki język jest w sam raz aby zrozumieć filozofię programowania (nie mówię od dawnym programowaniu w... pascalu czy c++, bardzo zamierzchłe czasy szkolne)

1

A czy srubokret jest w sam raz dla nowicjusza, zeby nauczyc sie budownictwa? ;f

Pisz w czym chcesz, jak Ci sie podoba C# to pisz w C#. Masz nawet fajna ksiazke udostepniona za darmo przez autora 4p.

0

Jest w sam raz.

1

Moim zdaniem, bardzo dobry i przyjemny język. Jeżeli piszesz programy na desktopy, to uważam go za jeden z lepszym, szczególnie jeśli piszesz głównie pod Windows. Z Javą miałem różne perypetie, ale bardzo często miałem jakieś drobne uwagi do niej. W C# na miejsce 10 problemów Javy, pojawiało się 9 ludzkich rozwiązań. Kiedy przesiadałem się na C# (3 lata temu), to nie mogłem zrozumieć jak mogłem tak długo korzystać z Javy i narzekać na jej niedociągnięcia, które naprawia C#.

Także ja uważam, że C# to bardzo dobry pomysł.

0
n0name_l napisał(a):

A czy srubokret jest w sam raz dla nowicjusza, zeby nauczyc sie budownictwa? ;f

Pisz w czym chcesz, jak Ci sie podoba C# to pisz w C#. Masz nawet fajna ksiazke udostepniona za darmo przez autora 4p.

Właśnie z tych materiałów korzystam. Bardzo dobry materiał do nauki :)

0

@lena(R) to może napisz co Ci nie pasowało w javie ?

3

@autor

  1. Brak przeciążania operatorów (niby do obejścia, ale ułatwia programowanie jeśli jest się do tego przyzwyczajonym)
  2. Brak typów wartościowych w klasach generycznych (osobiście zawsze mnie to denerwowało, gdy chciałem mieć kolekcję np. typu int, to byłem zmuszany do Integer w której mogły się pojawić null, których nie chciałem, czyli praktycznie zawsze musiałem sprawdzać co wrzucam do kolekcji)
  3. (Nie jestem w stanie przytoczyć przykładu, ale kilka razy szły wiązanki na Javę przez to) niby multiplatformowa, a zdarzały mi się przypadki kiedy pod Linux coś nie działało, a pod Windows tak i odwrotnie. Więc gdzie słynne "Piszesz raz, uruchamiasz gdzie chcesz"?
  4. Brak wyrażeń lambda, które bardzo ułatwiają programowanie i skracają kod. Tutaj nie da się tego opisać, jeśli ktoś nie korzystał.
  5. Brak wyjściowych i referencyjnych argumentów funkcji, które w bardzo fajny sposób daje się wykorzystać w C#, a w Javie ten problem trzeba było obchodzić.
  6. Tworzenie i wykorzystywanie eventów...no cóż...w C# są super rozwiązane, w Javie...nie da się tego porównać, w tym wypadku jest to dla mnie przepaść.
  7. Bardzo irytujące (przynajmniej mnie). Wszystkie metody klas domyślnie były wirtualne. A przecież zwykle nie chcemy tego, czyli trzeba ciągle dopisywać final przy definicjach metod.
  8. Zamiana kolekcji na tablice, czyli ToArray(), po prostu masakra w porównaniu do C#.
  9. (Coś, co często wykorzystuje) metody rozszerzające: dopisałem sobie kilka funkcji do klas, które są standardowo w C#. Teraz dołączam tylko własną bibliotekę do projektu i już mogę się cieszyć własnymi dodatkami do standardowych klas. Bez przeciążania, bez pamiętania nowych nazw. Po prostu, reszta sama się dzieje.
  10. Rzutowanie tablic (w Javie też do obejścia, ale ile razy można ręcznie rzutować każdy element tablicy? C# robi to za nas).
  11. var, niby mała rzecz, a cieszy. Nie zastanawiam się co metoda zwraca, C# się za mnie martwi. W Javie...no niestety.
  12. Stosunkowo słaba obsługa XML'i. C# po prostu łyka te pliki aż miło. Momentami ma się wrażenie że w ogóle pliku nie zauważył, a ten tak naprawdę siedzi w pamięci i czeka co dalej chce się z nim zrobić.
  13. (Subiektywne odczucie) denerwował mnie zawsze podział wyjątków w Javie, na te które trzeba obsłużyć przed uruchomieniem (w czasie kompilacji) i w trakcie działania. No proszę ja was, ale żaden wyjątek nie jest rzucany w momencie kompilowania kodu, więc po co to zamieszanie? Fajnie że metoda informuje jakie wyjątki rzuca, ale to ja wolałbym zarządzić tym, co chce złapać, a co nie i kiedy. Owszem niby mogę, ale wolałbym żeby było to na zasadzie "jak nikt nie złapie wyjątku, to niech program się wysypie" niż na siłę mnie uszczęśliwiać.
  14. (Rozwijając poprzednie) nigdy nie potrafiłem zrozumieć sensu rozdzielenia wyjątku od błędu w Javie. Dlaczego błąd (np. OutOfMemoryError) mam traktować inaczej niż wyjątek (np. NullPointerException)? Dla użytkownika to bez znaczenia, a dla mnie-programisty...no cóż niby potrzebne, ale trzeba pamiętać o tym podziale i kilka razy zdarzyło mi że dostać Error, chociaż nie było to dla mnie istotne jakiego typu i po co on w ogóle się pojawił. Istotny był dla mnie tylko fakt błędu, reszta i tak szła do loga. No i trzeba było poprawić w kilku miejscach z Exception na Throwable.
  15. Kwestia przyzwyczajenia, ale...skoro Java upiera się i każe mi pisać try-catch tam gdzie nie chcę, to czemu pozwala na nadpisanie danych w HashMapie, przez zwrócenie starej wartości? Albo czemu kiedy nie znajdzie podanego klucza w Mapie, to zwraca null? Dlaczego tutaj nie ma wyjątku????? Przecież tutaj dochodzi do przekłamywania na danych, można sobie zmienić dane w kolekcji i nawet o tym nie wiedzieć!
  16. Coś co bardzo często wykorzystuję, modyfikator readonly. W definicji takiego pola wpisuję jakąś standardową wartość, a w konstruktorze klasy, jak będę miał taką potrzebę (zajdą jakieś konkretne warunki), to sobie tą wartość zmienię. W Javie, jak coś jest final, to musi być zdefiniowane ALBO przy definicji pola ALBO w konstruktorze. Nie da rady i tu i tu, żeby wybrać w czasie kompilacji i uruchomienia odpowiednią wartość.

pewnie coś jeszcze by się znalazło, ale dawno już w Javie nie pisałem. Musiałbym napisać kilka linijek, żeby odświeżyć pamięć.

0

Nad czym sie tu zastanawiac:) bierz staz, zakuwaj, pisz i powodzenia:)

0
Lena(R) napisał(a):

@autor

  1. Kwestia przyzwyczajenia, ale...skoro Java upiera się i każe mi pisać try-catch tam gdzie nie chcę, to czemu pozwala na nadpisanie danych w HashMapie, przez zwrócenie starej wartości?

To jest normalne, ze jak wstawiasz do HashMapy wartosc o tym samym kluczu to wartosc ulegnie zmianie.

        HashMap<Integer,String> map = new HashMap<Integer, String>();
        map.put(10,"car");
        System.out.println(map.get(10)); // print car
        map.put(10,"house");
        System.out.println(map.get(10)); // print house
0
Kamilo21 napisał(a):
Lena(R) napisał(a):

@autor

  1. Kwestia przyzwyczajenia, ale...skoro Java upiera się i każe mi pisać try-catch tam gdzie nie chcę, to czemu pozwala na nadpisanie danych w HashMapie, przez zwrócenie starej wartości?

To jest normalne, ze jak wstawiasz do HashMapy wartosc o tym samym kluczu to wartosc ulegnie zmianie.

        HashMap<Integer,String> map = new HashMap<Integer, String>();
        map.put(10,"car");
        System.out.println(map.get(10)); // print car
        map.put(10,"house");
        System.out.println(map.get(10)); // print house

Ok, a co jeśli przez przypadek dodałeś drugi raz element o tym samym kluczu? Nie tak celowo jak w Twoim kodzie? Albo inaczej, nie masz pewności czy klucz już w mapie istnieje i albo w ciemno wstawiasz element z kluczem, albo najpierw sprawdzasz. Java w momencie put dla tego samego klucza zwraca poprzednią wartość, w C# poleci wyjątek, bo nie można dodać dwa razy elementu o tym samym kluczu (nadpisać istniejący można, tylko w inny sposób).

Tak jak napisałem na początku, to kwestia przyzwyczajenia się, ale mnie to trochę irytowało w Javie. Bo i tak w większości przypadków trzeba było sprawdzić czy klucz istnieje przed putem, czy inną operacją, bo to co metoda zwraca może być również null, ale on może oznaczać, że poprzednio pod danym kluczem był null albo właśnie dodałeś nowy klucz i obiekt. To trochę dwie różne sytuację i je trzeba ciągle sprawdzać.

0
Lena(R) napisał(a):
  1. Brak typów wartościowych w klasach generycznych (osobiście zawsze mnie to denerwowało, gdy chciałem mieć kolekcję np. typu int, to byłem zmuszany do Integer w której mogły się pojawić null, których nie chciałem, czyli praktycznie zawsze musiałem sprawdzać co wrzucam do kolekcji)

Scala już na to pozwala ;)

Lena(R) napisał(a):
  1. (Nie jestem w stanie przytoczyć przykładu, ale kilka razy szły wiązanki na Javę przez to) niby multiplatformowa, a zdarzały mi się przypadki kiedy pod Linux coś nie działało, a pod Windows tak i odwrotnie. Więc gdzie słynne "Piszesz raz, uruchamiasz gdzie chcesz"?

Jak ktoś korzysta z mechanizmów specyficznych dla danego OSa to tak potem jest. To wina programisty a nie Javy.

Lena(R) napisał(a):
  1. Brak wyrażeń lambda, które bardzo ułatwiają programowanie i skracają kod. Tutaj nie da się tego opisać, jeśli ktoś nie korzystał.

Jest Guava która pozwala na stosowanie map-filter-reduce no i w javie 1.8 lambdy mają już być. Poza tym nie przesadzałbym z użytecznością lambdy, bo w realnych sytuacjach przyda się to bardzo rzadko ;]

Lena(R) napisał(a):
  1. Zamiana kolekcji na tablice, czyli ToArray(), po prostu masakra w porównaniu do C#.

Masakrą to jest w ogóle pomysł zamieniania kolekcji na tablice :P Jedyne uzasadnienie jakie widzę to konieczność przekazania tablicy do jakiejś starej metody, napisanej 700 lat temu, która wymaga tablicy jako argumentu.

Lena(R) napisał(a):
  1. (Coś, co często wykorzystuje) metody rozszerzające: dopisałem sobie kilka funkcji do klas, które są standardowo w C#. Teraz dołączam tylko własną bibliotekę do projektu i już mogę się cieszyć własnymi dodatkami do standardowych klas. Bez przeciążania, bez pamiętania nowych nazw. Po prostu, reszta sama się dzieje.

o_O To akurat wygląda mi na bardzo dziwne podejście, szczególnie że potem nie wiesz co faktycznie w tych klasach jest, a co sam dodałeś.

Lena(R) napisał(a):
  1. Rzutowanie tablic (w Javie też do obejścia, ale ile razy można ręcznie rzutować każdy element tablicy? C# robi to za nas).

Nie rozumiem tego punktu. Przecież można w javie zrobić toArray z konkretnym typem...

Lena(R) napisał(a):
  1. var, niby mała rzecz, a cieszy. Nie zastanawiam się co metoda zwraca, C# się za mnie martwi. W Javie...no niestety.

Nie bardzo rozumiem w czym problem. Chyba tylko jak kodujesz za pomocą lodówki. Normalne IDE bez problemu uzupełnia ci typ.

Jeśli chodzi o wyjątki to logiczne wydaje mi się że nie można tak samo traktować NullPointerException, który może polecieć praktycznie w każdej linijce kodu i do tego zawsze oznacza jakiś błąd, a jakiś biznesowy wyjątek z serii "nie masz środków na koncie" albo "podałeś złe hasło".
A jeśli gdzieś musialeś stosować pokemon exception handling ("gotta catch em all" :P) to znaczy że kod był wtfem :P

0
Shalom napisał(a):

Scala już na to pozwala ;)

Chyba za dużo zadajesz się z niektórymi kolegami z forum. :P

Poza tym nie przesadzałbym z użytecznością lambdy, bo w realnych sytuacjach przyda się to bardzo rzadko ;]

No jak ich nie ma, to się ich nie używa. Jak są, to 80% kodu powstaje z ich udziałem.

o_O To akurat wygląda mi na bardzo dziwne podejście, szczególnie że potem nie wiesz co faktycznie w tych klasach jest, a co sam dodałeś.

Wiesz, bo IDE pokazuje inną ikonkę przy metodach rozszerzających. ;)
Sam nie jestem jakimś ich zwolennikiem, bo są miejsca, w których się rzeczywiście przydają, natomiast niektórzy ludzie (zwłaszcza fetyszyści Ruby) nadużywają ich w patologiczny sposób zastępując nimi prawidłową hierarchię normalnych klas.

Nie bardzo rozumiem w czym problem. Chyba tylko jak kodujesz za pomocą lodówki. Normalne IDE bez problemu uzupełnia ci typ.

Nie sądzę, żeby jakieś IDE potrafiło podpowiedzieć nazwę typu, którego zmienną masz właśnie zamiar zadeklarować. :)

Jeśli chodzi o wyjątki to logiczne wydaje mi się że nie można tak samo traktować NullPointerException, który może polecieć praktycznie w każdej linijce kodu i do tego zawsze oznacza jakiś błąd, a jakiś biznesowy wyjątek z serii "nie masz środków na koncie" albo "podałeś złe hasło".

Oczywiście, że nie. Ani brak środków na koncie, ani podanie złego hasła, to nie jest powód do wyjątku w ogóle!

0

No jak ich nie ma, to się ich nie używa. Jak są, to 80% kodu powstaje z ich udziałem.

Nie wiem gdzie ty pracujesz ale w życiu wyprodukowałem sporo kodu w pythonie (gdzie lambdy są) i w javie (gdzie guava dostarcza odpowiedniego mechanizmu a intelliJ zwija to do postaci która wygląda jak lambda) i nawet 1% kodu nie był napisany z użyciem lambdy. Chyba ze chodzi ci o to że w większości projektów lambda się pojawi? To na pewno, ale to będzie raptem kilka miejsc a nie cały kod :P
Zresztą jak ktoś bardzo chce to jest np. http://code.google.com/p/lambdaj/ :)

Nie sądzę, żeby jakieś IDE potrafiło podpowiedzieć nazwę typu, którego zmienną masz właśnie zamiar zadeklarować.

Nie bardzo rozumiem. To jest zupełnie normalne że jak deklaruje zmienną i przypisuje jej wartość zwracaną przez jakąś funkcję to IDE podpowiada mi jakiego typu powinna być ta zmienna. Zresztą mogę napisać tylko samo wywołanie funkcji a IDE samo podpowie mi żebym przypisał sobie wartość zwracaną i zrobi mi odpowiednią zmienną. Więc wracając do meritum: nie wiem jak to tam w VisualStudio jest, ale Eclipse czy IntelliJ bez problemów potrafią podpowiedzieć nazwę typu ;]

0
Shalom napisał(a):

Nie wiem gdzie ty pracujesz ale w życiu wyprodukowałem sporo kodu w pythonie (gdzie lambdy są) i w javie (gdzie guava dostarcza odpowiedniego mechanizmu a intelliJ zwija to do postaci która wygląda jak lambda) i nawet 1% kodu nie był napisany z użyciem lambdy. Chyba ze chodzi ci o to że w większości projektów lambda się pojawi? To na pewno, ale to będzie raptem kilka miejsc a nie cały kod :P

Chodzi mi o to, że jakieś 90% pętli zastępuje się wywołaniem metody rozszerzającej z lambdą, że 90% bibliotek korzysta z różnych fluent API, które to przyjmują lambdy, więc jest ich w kodzie masa, tak na oko pojawiają się w 80% metod. A z drugiej strony dzięki nim kodu jest ze dwa razy mniej.
Ergo - nie pracuję w Javie, więc lambd używam. To jest naprawdę wygodne.

Więc wracając do meritum: nie wiem jak to tam w VisualStudio jest, ale Eclipse czy IntelliJ bez problemów potrafią podpowiedzieć nazwę typu ;]

To znaczy, że jak zechcesz sobie nagle zadeklarować zmienną typu MySuperMadafakaClass, to Eclipse odczyta Twoją myśl i wpisze w edytorze: MySuperMadafakaClass? Wątpię. ;)
A druga kwestia to to, że używając var, nie muszę pamiętać nieraz bardzo długiej nazwy typu zwracanego przez metodę. Piszę po prostu var zmienna = _jakieśtamCoś.GetCośTamFajnego().

3

Shalom, chyba nie pracowałeś w C# nad jakimkolwiek większym projektem, bo to co piszesz o C# i VS to - z całym szacunkiem do Twojej wiedzy z tematu javy - bzdury. Używam var wszędzie gdzie mogę, nie muszę definiować typu, nie muszę korzystać z podpowiedzi środowiska, po prostu var zmienna = wartość i już. Pracę z C# zaczynałem od wersji języka, w której nie było tego słowa kluczowego, nowsza wersja, która to wprowadziła, była dla mnie jak objawienie. Skraca o dobre kilkanaście procent czas poświęcony na klepanie liter, które tak naprawdę nie stanowią kodu, a więc są stratą czasu. Kolejne kilkadziesiąt procent krócej jest dzięki Linq i lambdom. Somekind słusznie napisał, że mnóstwo kodu opiera się o lambdy - większość kodu i w moim obecnym, i w poprzednich dwóch miejscach pracy powstawała z użyciem lambd, albo chociaż extension methods Linq. Niesamowicie skracają czas, bo np. pozwalają traktować liniowo pętle (z punktu widzenia programisty), ułatwiają też, a często wręcz umożliwiają robienie bardziej skomplikowanych zapytań do bazy danych czy innych źródeł danych. Zapytania na zapytaniach, późne wiązanie danych, yield return - mistrzostwo świata.
Java to świetny język, jednak ma swoje braki i w niektórych miejscach bywa niewygodna. C#, to tu ukrywać, na początku czerpał z javy garściami, nie pierwszy i nie ostatni raz MS kradnie rozwiązania od konkurencji. Jednak kiedy powstawał C# znane były wady javy, a jako nowy język nie był obarczony balastem wstecznej kompatybilności, dlatego po prostu JEST lepszy. Programowałem w kilkunastu językach (w tym w java), sześć czy siedem poznałem dość dobrze i muszę powiedzieć, że wygodniejszym językiem niż C# jest tylko nowsza wersja tego języka. Zastrzegam, że od sześciu lat nie jestem na bieżąco ani z javą, ani jej środowiskami programistycznymi, ale opinie przytaczane przez kolegów utwierdzają mnie w moim zdaniu.

0

Witam,

Również chcę przebranżowić się i zrobić to samo co kolega zakładający post. Ja niestety nie mam na tyle szczęścia i nie mam jak na razie szansy dostać pracy w jakiejkolwiek firmie programistycznej, choć programowanie traktuje bardziej jako pasję niż możliwość zarabiania;( Również polecam C#. Od jakiegoś czasu trochę w nim skrobię i uważam, że jest OK. Dla kogoś, kto od 9 lat pisał w VB (nawet komercyjne projekty z tego wypaliły) przesiadka na C# nie stanowiła dużego problemu. Ucz się UML (mnie ciężko się do tego zabrać), wzorców projektowych (nie tylko dla pracy, ale głównie dlatego, że to ciekawe jest). Wzorce załatwiają w sposób elegancki popularne problemy (nawet w VB dało się to zauważyć). Poucz się SQL (przydaje się czasem jak trzeba coś zrobić na bazie, a nie ma pod ręką kogoś, kto zna dobrze SQL ). Ostatnio uczę się ASP .NET i uważam, że też można ciekawe rzeczy z tym robić, więc może też przy okazji ćwiczenia C# warto poćwiczyć tę technologię. A i obowiązkowo ADO - dostęp do baz danych to ważna sprawa. Trzymam kciuki w rozwijaniu nowych umiejętności i za powodzenie w pracy.

1
Lena(R) napisał(a):
  1. Brak typów wartościowych w klasach generycznych (osobiście zawsze mnie to denerwowało, gdy chciałem mieć kolekcję np. typu int, to byłem zmuszany do Integer w której mogły się pojawić null, których nie chciałem, czyli praktycznie zawsze musiałem sprawdzać co wrzucam do kolekcji)

Scala już na to pozwala ;)

Scala może tak, ale Java nie, mówimy o Javie.

Lena(R) napisał(a):
  1. (Nie jestem w stanie przytoczyć przykładu, ale kilka razy szły wiązanki na Javę przez to) niby multiplatformowa, a zdarzały mi się przypadki kiedy pod Linux coś nie działało, a pod Windows tak i odwrotnie. Więc gdzie słynne "Piszesz raz, uruchamiasz gdzie chcesz"?

Jak ktoś korzysta z mechanizmów specyficznych dla danego OSa to tak potem jest. To wina programisty a nie Javy.

Czyli nie jest w 100% przenoszalna. Czyli język jak każdy inny. Więc po co się chwalą multiplatformowością? Szkoda że nie pamiętam co u mnie nie działało, ale jestem prawie na 100% pewien, że chodziło o zdarzenia, że coś nie tak działało z nimi pod Javą (w sensie samo rzucanie lub odbieranie ich).

Lena(R) napisał(a):
  1. Brak wyrażeń lambda, które bardzo ułatwiają programowanie i skracają kod. Tutaj nie da się tego opisać, jeśli ktoś nie korzystał.

Jest Guava która pozwala na stosowanie map-filter-reduce no i w javie 1.8 lambdy mają już być. Poza tym nie przesadzałbym z użytecznością lambdy, bo w realnych sytuacjach przyda się to bardzo rzadko ;]

Przydaje się bardzo rzadko? Jak wspomnieli moi przedmówcy, 80% metod to wykorzystuje, a proste operacje, które na piechotę trzeba rozwiązywać pętlą for w której w if-ach sprawdza się coś i ewentualnie wyniki pakuje do kolekcji, dzięki lambda załatwia się w jednej prostej, krótkiej, o wiele bardziej zrozumiałej linijce, to to ma być nieprzydane? Połowa mojego kodu zazwyczaj się o lambda opiera, bo to jest bardzo wygodny mechanizm.

Lena(R) napisał(a):
  1. Zamiana kolekcji na tablice, czyli ToArray(), po prostu masakra w porównaniu do C#.

Masakrą to jest w ogóle pomysł zamieniania kolekcji na tablice :P Jedyne uzasadnienie jakie widzę to konieczność przekazania tablicy do jakiejś starej metody, napisanej 700 lat temu, która wymaga tablicy jako argumentu.

A to dziwne, bo nowe metody w różnych klasach, też czasem chcą tablic. Może Ty żyjesz w innych czasach? Poza tym, czasami chce się przekazać część lub całą kolekcję. I dziwne, że tutaj C# bardzo często opakowane w jakiejś klasie kolekcje, zwraca je przy pomocy tablic...hmmm...może dlatego żeby dać minimalną szansę na zmodyfikowanie tego co jest kolekcji?

Lena(R) napisał(a):
  1. (Coś, co często wykorzystuje) metody rozszerzające: dopisałem sobie kilka funkcji do klas, które są standardowo w C#. Teraz dołączam tylko własną bibliotekę do projektu i już mogę się cieszyć własnymi dodatkami do standardowych klas. Bez przeciążania, bez pamiętania nowych nazw. Po prostu, reszta sama się dzieje.

o_O To akurat wygląda mi na bardzo dziwne podejście, szczególnie że potem nie wiesz co faktycznie w tych klasach jest, a co sam dodałeś.

Dlaczego miałbym nie wiedzieć? Czy Ty korzystałeś kiedyś z C#? Zresztą nawet jakbym zapomniał, to co się stanie?
Wolę zapomnieć i mieć zawsze pod ręką metody które co chwila wykorzystuję niż pisać długi kod co chwila, który jest tym samym wszędzie (chyba do tego właśnie służą metody, żeby nie powtarzać kodu).

Lena(R) napisał(a):
  1. Rzutowanie tablic (w Javie też do obejścia, ale ile razy można ręcznie rzutować każdy element tablicy? C# robi to za nas).

Nie rozumiem tego punktu. Przecież można w javie zrobić toArray z konkretnym typem...

No ale jak już masz tablicę jednego typu, to nie zrzutujesz jej na inny typ w prosty i oczywisty sposób. Kod typu

Object[] elem = {1, 3, 5, 6};
Integer[] i = (Integer[]) elem;

Opluje Cię wyjątkiem, a w C# działa bez problemu. A niektóre metody w Javie zwracały tablicę Object, szczególnie kiedy korzysta się z refleksji. Czasami wiem co tam siedzi i chciałbym szybko zrzutować. Ale w Javie się nie da. Również to nie zadziała:

Object[] elem = {1, 3, 5, 6};
Integer[] i = elem.toArray(/*coś tutaj ewentualnie*/);

Bo tablica w Javie nie ma metody toArray. Więc zostaje albo ręczne rzutowanie przez for i samemu każdy element przepisujemy, albo

Object[] elem = {1, 3, 5, 6};
Integer[] i = Arrays.copyOf(elem, elem.length, Integer[].class);

ale nie każdy o tym musi wiedzieć, albo można zapomnieć o tym sposobie, jeśli dla tablic jest to wyjątkowo inaczej wykorzystywane niż dla innych typów.

Lena(R) napisał(a):
  1. var, niby mała rzecz, a cieszy. Nie zastanawiam się co metoda zwraca, C# się za mnie martwi. W Javie...no niestety.

Nie bardzo rozumiem w czym problem. Chyba tylko jak kodujesz za pomocą lodówki. Normalne IDE bez problemu uzupełnia ci typ.

To nie jest kwestia IDE, zresztą @ŁF chyba wyjaśnił wystarczająco jak to działa. Ty chyba naprawdę nigdy nie używałeś C# w dużym projekcie, skoro piszesz takie rzeczy.

1 użytkowników online, w tym zalogowanych: 0, gości: 1