Миграция из C# в Java: Часть 2

Продолжим тему миграции. Перевод первой части пресдтавлен здесь, а ниже представлен перевод части 2. А в это время у Эрика уже имеется часть 4.

---

Как я уже упоминал в части 1, прошло уже прочти десять лет с тех пор, как я последний раз писал на Java. Очевидно, что этого достаточно, чтобы подавить некоторые наиболее неприятные воспоминания. Например, я совсем забыл, как работает следующий код:

String a = new String("foo");
String b = new String("foo");
if (a == b)
{       // этого никогда не случится
} 

В C# используя оператор == вы получаете ожидаемое. В Java == значит лишь, что две строки представляют собой один обхъект, а не равенство самих строк.

Причина: Перегрузка Операторов

Более широко, возарвщение к Java заставляет меня понять, насколько я разбираюсь в перегрузке операторов в C#.

Я не говорю, что считаю перегрузку операторов действительно полезной для моих собственных классов. Главным образом, я считаю это лишь способом позволить программистам создавать плохой код. Я допущу использование перегрузки операторов в малых долях в Sawdust для упрощения манипуляций с 3D точками и векторами, но я мог-бы обойтись и без них.

Те мне менее, мне действительно нравится использование перегрузки операторов в классах .NET Framework:

• Использование == для сравнения строк очень интуитивно.



• Естественно выглядит использование < и > для сравнение объектов DateTime.



• Доступ к элементам Dictionary по индексу с помощью [] кажется верным.

Ничего из этого не доступно в Java, и я теряю их всех.

Особенно это касается строк.

Однако это еще не так огорчает.

Ты Доолжен Подшутить Надо Мной.

Что действительно шокирует, так это то, что постратил неделю или около того на написание неверного кода и не получил никаких предупреждений от среды разработки. Я не понимал, что == не может быть использован для сравнения строк, пока не обратил внимание на некорректные результаты, выдаваемые приложением, и не начал раскапывать причины. Думаю, какое-нибудь предупреждение на этот случай было бы к месту.

И откровенно я был сильно удивился, когда не получил ни одного. Я считаю верно - такое ощущение, что Eclipse делает удивительную работу по части отслеживания ошибок и предупореждений.

• Когда я получаю ошибку или предупреждение, Eclipse указывает мне на них несколькими способами совсем не прерывая мою работу. Вкладка Problems дает мне полный список. В редакторе я получаю желтые или красные пометки. На левой границе отображаются иконки для каждой строки с ошибкой. В Explorer файлы с ошибками также помечаются иконками.



• Когда я набираю название нового класса, Eclipse проверяет имя на каждом новом символе и предупреждает, если оно совпадает с именем, используемым где-лиюбо еще.



• Вчера после полудня я открыл окно моего офиса. Eclipse заметил это, воспользовался моим IP-адресом для определения моего местоположения, проверил погоду для Champaign, обнаружил в прогнозе дождь и предупредил меня, что следует не забыть закрыть окно перед уходом домой. :-)

Серьезно, Eclipse самая болтливая среда разработки что я использовал, и нет, я не жалуюсь. Я нахожу Eclipse чрезвычайно приятным. Он придупреждает иеня о многом, но эти предупреждения непосредственны, уместны и полезны.

И поэтому я немогу поверить, что никакая часть среды Eclipse не решилась предупредить меня о сравнении строк. Мои ожидания были очень высоки. Eclipse предупреждает меня так часто, что я даже заметил, что пытаюсь сидеть в правильной позе, лишь бы не обратить на это его внимание. Но по некоторым причинам, Eclipse молча принял использование == для сравнения строк, даже если такое использование в большинстве случаев некорректно.

В Итоге.

Думаю, я только здесь закончил свои жалобы.

Я сожадею, что этот пост в целом позитивен к C# и негативен к Java. Чтобы удержать баланс, в части 3 я остановлюсь на некоторых областях, где Eclipse выглядит лучше, чем Visual Studio. Way better.  :-)