W przypadku programistów C #, którzy chcą nauczyć się języka Java, czy są jakieś duże różnice między tymi dwoma językami, na które należy zwrócić uwagę?
Może niektórzy ludzie zakładają, że jest tak samo, ale są pewne ważne aspekty, których nie należy przeoczyć? (albo możesz naprawdę schrzanić!)
Może pod względem konstrukcji OOP, sposobu działania GC, referencji, związanych z wdrażaniem itp.
Odpowiedzi:
Kilka kłopotów z mojej głowy:
byte jest podpisany w Javie (niestety)staticon miał niejawne odwołanie do wystąpienia klasy zawierającej.tutaj jest bardzo obszerne porównanie dwóch języków:
http://www.25hoursaday.com/CsharpVsJava.html
Dodano: http://en.wikipedia.org/wiki/Comparison_of_Java_and_C_Sharp
Dziwię się, że nikt nie wspomniał o właściwościach, czymś dość podstawowym w C #, ale nieobecnym w Javie. C # 3 i nowsze wersje mają również automatycznie implementowane właściwości. W Javie musisz używać metod typu GetX / SetX.
Inną oczywistą różnicą są wyrażenia LINQ i lambda w C # 3, których nie ma w Javie.
W Javie brakuje kilku innych prostych, ale użytecznych rzeczy, takich jak ciągi dosłowne (@ ""), przeciążanie operatorów, iteratory używające wydajności i preprocesora, których również brakuje w Javie.
Jednym z moich ulubionych w C # jest to, że nazwy przestrzeni nazw nie muszą być zgodne z fizyczną strukturą katalogów. Bardzo podoba mi się ta elastyczność.
Jest wiele różnic, ale przychodzą mi na myśl:
.equalsjest tym, czego musisz użyć.
.NET zreifikował typy generyczne; Java usunęła typy generyczne.
Różnica jest następująca: jeśli masz ArrayList<String>obiekt, w .NET możesz powiedzieć (w czasie wykonywania), że obiekt ma typ ArrayList<String>, podczas gdy w Javie, w czasie wykonywania, obiekt jest typu ArrayList; Stringczęść jest tracona. Jeśli umieścisz Stringobiekty niebędące obiektami w ArrayList, system nie może tego wymusić, a dowiesz się o tym dopiero po próbie wyodrębnienia przedmiotu, a rzucanie się nie powiedzie.
Stringobiekty w tym wykazie, bez dokonywania niezaznaczone obsady, gdzieś , a kompilator będzie prawidłowo ostrzec cię w tym momencie, że kompilator nie może sprawdzić ogólnych granic. Dopóki lista jest zawsze przechowywana w zmiennej typu List<String>, próby wstawienia do niej obiektu innego niż łańcuch nie będą się kompilować.
addmetodę (ponownie, przez odbicie). Czy system odrzuci Stringobiekt niebędący przedmiotem od razu, czy tylko podczas rzucania wyniku get?
List. Możesz mieć obiekty o typach od List, takich jak ArrayListi LinkedList. (Ważne jest, aby używać Listzamiast ArrayListpodczas przekazywania ich, ale nie zmienia to faktu, że nie można powiedzieć new List().)
Jedną rzeczą, której brakuje mi w C # w Javie, jest wymuszona obsługa sprawdzonych wyjątków. W języku C # często zdarza się, że ktoś nie jest świadomy wyjątków, które metoda może rzucać, i jest zdany na łaskę dokumentacji lub testów, aby je odkryć. Inaczej jest w Javie z zaznaczonymi wyjątkami.
Java ma autoboxing dla prymitywów, a nie typów wartości, więc chociaż System.Int32[]jest tablicą wartości w C #, Integer[]jest tablicą odwołań do Integerobiektów i jako taka nie nadaje się do obliczeń o wyższej wydajności.
Żadnych delegatów ani wydarzeń - musisz używać interfejsów. Na szczęście możesz tworzyć klasy i implementacje interfejsów w tekście, więc nie jest to taka wielka sprawa
x => x.Fooczy new Bar() { public void M(SomeType x) { return x.Foo; } }- kogo obchodzi, żeby kod był 10 razy krótszy?
Wbudowana funkcja daty / kalendarza w Javie jest okropna w porównaniu z System.DateTime. Jest tutaj wiele informacji na ten temat: Co jest nie tak z Java Date & Time API?
Niektóre z nich mogą być pułapkami dla programisty C #:
Ponadto Java nie ma wszystkich tych samych funkcji, które zapewniają GAC i zestawy o silnych nazwach. Jar Hell to termin określający, co może pójść nie tak podczas łączenia / odwoływania się do zewnętrznych bibliotek.
Jeśli chodzi o pakowanie / wdrażanie:
Jedyną rzeczą, która wyskakuje b / c, jest na mojej liście wywiadów, jest to, że w Javie nie ma "nowego" odpowiednika słowa kluczowego do ukrywania metod i dlatego nie ma ostrzeżenia kompilatora "powinieneś umieścić tutaj nowe". Przypadkowe ukrycie metody, gdy chcesz zastąpić, prowadzi do błędów.
(na przykład edytuj) Przykład, B pochodzi od A (używając składni C #, Java zachowuje się tak samo, jak ostatnio sprawdzałem, ale nie emituje ostrzeżenia kompilatora). Czy dzwoni foo A, czy foo B? (Wzywa się A, prawdopodobnie zaskakując programistę, który zaimplementował B).
class A
{
public void foo() {code}
}
class B:A
{
public void foo() {code}
}
void SomeMethod()
{
A a = new B(); // variable's type is declared as A, but assigned to an object of B.
a.foo();
}
newmetody celowego ukrycia - albo nie ostateczne, więc są zastępowane, a nie ukrywane.
Java nie ma LINQ, a dokumentacja to piekło. Tworzenie interfejsów użytkownika w Javie jest trudne, tracisz wszystkie dobre rzeczy, które dał nam Microsoft (WPF, WCF itp.), Ale otrzymujesz trudne w użyciu, mało udokumentowane „interfejsy API”.
Jedynym problemem, na który natknąłem się do tej pory podczas pracy z Javą pochodzącą z C #, są wyjątki i błędy.
Na przykład nie można złapać błędu braku pamięci za pomocą catch (wyjątek e).
Więcej informacji znajdziesz poniżej:
dlaczego jest-java-lang-outofmemoryerror-java-heap-space-not-catch
Minęło tak dużo czasu, odkąd pracowałem w Javie, ale podczas tworzenia aplikacji zauważyłem od razu model zdarzeń w języku C #, przeciąganie i upuszczanie w języku C # w porównaniu z Menedżerami układów w Swing (jeśli robisz programowanie aplikacji) oraz obsługę wyjątków w Java upewniająca się, że wychwycisz wyjątek i C # nie jest wymagane.
W odpowiedzi na bardzo bezpośrednie pytanie w tytule:
„Programiści C # uczący się języka Java, jakie są największe różnice, które można przeoczyć?”
Odp .: Fakt, że Java jest znacznie wolniejsza w systemie Windows.