Дизайн - это вам не…

Сегодня второй день в должности дизайнера.  Собственно, что я выяснил:

"Дизайн - это вам не программинг, тут головой думать надо!"

Пока все.

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

Оригинал здесь.

---

До 2002 года я открыто отвергал большинство IDE. Они казались мне слишком настойчивыми. Они постоянно пытались контролировать мою систему сборки или формат кода. Если я хочу раскрыть какие-то вещи, мне нужно что-то взамен. Долгое время обмен не казался мне честным. THINK C на Macintosh был единственной IDE, которая действительно мне нравилась.

Visual Studio .NET 2002 стала первой IDE для Windows, расположившей меня в себе. Я до сих пор использую vi или emacs почти каждый день, но допускаю, что стал больше использовать Visual Studio.

В прошлом году я перешел на Visual Studio 2005 и полюбил ее. Это настолько великолепный продукт, что меня беспокоило, каков же будет следующий релиз. И вот вышла Visual Studio 2008, вероятно, вскоре я попробую ее. Но Visual Studio 2005 похожа на "Если оно работает, так и нечего беспокоиться". Последнее, что мне нужно, это чтобы она стала в чем-то хуже, потому как я совершенно не представляю, как она могла бы быть лучше.

Я догадываюсь, когда что-то уже появляется в IDE, просто у меня не очень хорошее воображение. :-)

Я начал использовать Eclipse несколько недель назад и теперь понимаю, где Visual Studio находит пространство для улучшений. Я думаю, Eclipse удивительна, и я лишь прошелся по поверхности.

Во всяком случае, вот пара избранных мной на этот раз фич Eclipse:

Постоянная сборка.

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

Конечно, теперь я понимаю, что Eclipse не имеет такой команды, потому как сборка выполняется автоматически и постоянно. В действительности, такая возможность меня зацепила. Однажды это привело в замешательство, однако в остальном оно Просто Работает. Я делаю изменения в коде, сохраняю файл и панель Problems автоматически показывает существующие предупреждения и ошибки. Приятно.

В действительности, этим утром я потревожил Visual Studio 2005 чтобы исправить баг. После внесения изменений, я сохранил файл и уставился вниз экрана в ожидании запуска компиляции. Лишь несколько секунд спустя я догадался нажать Ctrl-Shift-B.

Быстрая правка.

Мне действительно по душе функция Quick Fix в Eclipse. В основном, всякий раз, получая ошибку компиляции или предупреждение, я ставлю текстовый курсор на "проблемное" место и жму Ctrl-1. Это вызывает инструмент Quick Fix, который отображает окно со списком путей решения данной проблемы. Например, если я пытаюсь вызвать несуществующий метод, мне предлагается создать его.

Студия предлагает сходные возможности (например, Generate Method Stub), но Quick Fix кажется более оригинальным. Мне почти всегда предлагается несколько вариантов разрешения ситуации, включая предпросмотр результата быстрой правки.

Это особенно удобно, если имеешь дело с исключениями. Я большей частью испытываю неприязнь к тому, что Java заставляет объявлять, какие исключения могут быть брошены из метода. Ctrl-1 дает мне также возможность с легкостью добавить объявления типов исключений или блоки try/catch.

В завершение.

Ясно, что я новичок в Eclipse, так что мои представления о ее возможностях могут быть неверными. И как я и сказал, я лишь начинаю. Во время написания данного поста я обнаружил "Generate Constructor Using Fields...". Жаль, что я нашел это немного раньше. :-)

В любом случае, вы можете свободно меня корректировать, дополнять или обвинять в невежестве или называть 7 причин, по которым я должен использовать IntelliJ.

Но главным образом я лишь говорю, что опыт с Eclipse дал мне намного большие перспективы по части IDE в общем. Сравнивая Visual Studio и Eclipse, я не могу назвать, который из них однозначно лучше. По большей части я впечатлен, что эти два соперника могут научиться так многому друг у друга.

Миграция из 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.  :-)