Ужас какой. Для этих целей нужно заводить константы, которые описывают, зачем такое нужно, а еще лучше — специальные properties в файлах настройки программы.
Согласен. Я не очень понимаю, почему люди, делавшие спецификацию порешили именно так, но получается, что делать по спецификации значит вредить читаемости; делать так, как сделано в компиляторе плохо, потому что сообщение об ошибке мягко говоря не адекватно. Править короче, надо и там, и там, имхо.
Мысль хорошая, спасибо. Рекомендую добавить возможность стилизации: кастомизация иконок к примеру. Алсо, было бы неплохо добавить конструкторы к чекерам, которые бы принимали идентификатор ресурса вместо строки, чтобы не писать везде getString(). Правда, тогда придется еще объект ресурсов передавать, или контекст.
Я поставил минус, потому что «вот опять».
Очередной разработчик, прочитав хорошие книжки, решает состряпать статью на полтора абзаца о том, что только что прочитал. Ну зачем? Везде, где вы спросите об искусстве программирования, вас ткнут в эти книги. И только читая их целиком, можно понять, что упомянутые тезисы действительно работают. Потому что авторы посвятили этому целые книги, потратили гораздо больше, чем пару часов на написание своего труда и имеют гораздо больший, чем несколько лет, опыт в разработке. Так зачем их в очередной раз пытаться пересказать на одной страничке?
Поделитесь лучше собственным опытом разработки чего-нибудь, укажите какие подводные камни посчастливилось повстречать, какие проблемы удалось решить. Принесет гораздо больше пользы.
Я считаю, что каждый случай нужно рассматривать отдельно. Да и что считать ошибкой? Расхождение с требованиями? А если требования составлены плохо, в этом тоже программист виноват? Или, может нужно винить не программиста, который не тестировал код, а компанию, в которой этот код написан? Нет здесь однозначного ответа. Нужно каждый раз определять виновного и наказывать его, в этом нет сомнений.
А. ну так это проблемы HotSwap — изменения подхватываются внутри метода only. Дело в том, что JRebel работает по другому — он прямо в контейнер засовывает новый байткод класса, а поэтому может работать с чем угодно — можно добавлять методы и поля классов, менять методы и прочее. Не работает только смена super-класса. Алсо, JRebel в последнее время научился вроде как подхватывать и аннтационные изменения, т.е. работать с CDI, но я не проверял. Алсо, JRebel требует от сервера больший размер PermGen. Для работы JRebel в идее нужен плагин(но это только чтобы дебаг работал по измененным классам).
И для идеи не обязательно делать сборку самостоятельно. Просто в ней надо сказать, чтобы она классы компилировала туда же, куда собирает ваш сборщик — ant, maven и так далее.
Статья хорошая, спасибо. Но не раскрыто самое главное — реализация механизма смены тем для одного и того же приложения(скины). Ведь это можно делать практически в один вызов.
Очередной разработчик, прочитав хорошие книжки, решает состряпать статью на полтора абзаца о том, что только что прочитал. Ну зачем? Везде, где вы спросите об искусстве программирования, вас ткнут в эти книги. И только читая их целиком, можно понять, что упомянутые тезисы действительно работают. Потому что авторы посвятили этому целые книги, потратили гораздо больше, чем пару часов на написание своего труда и имеют гораздо больший, чем несколько лет, опыт в разработке. Так зачем их в очередной раз пытаться пересказать на одной страничке?
Поделитесь лучше собственным опытом разработки чего-нибудь, укажите какие подводные камни посчастливилось повстречать, какие проблемы удалось решить. Принесет гораздо больше пользы.
И для идеи не обязательно делать сборку самостоятельно. Просто в ней надо сказать, чтобы она классы компилировала туда же, куда собирает ваш сборщик — ant, maven и так далее.