Авторское отступление: Не закидывайте камнями те, кому выпало писать под разные браузеры!
В моей работе из-за использования ActiveX-компонентов сейчас поддерживается только IE. Поэтому дальнейшее изложение касается только различных версий IE.

IE10 — это особый браузер. Многое из того, что было верно для предыдущий версий IE, перестало работать.
Рассматриваются только ошибки JavaScript, возникшие при миграции legacy-кода. Различие в CSS выходит за рамки данной статьи.

Навеяно топиком о смерти MVC.

Чтобы разобраться в том, что происходит, давайте пойдем от принципов ООП.
Класс объектов в ООП инкапсулирует данные объекта с его поведением.
Вся сложность в разделении предметной области на объекты.
Здесь под «предметной областью» я понимаю также техническое окружение (БД, сеть и т.д.)

Распространенной практикой в наши дни стало создание легковесных POJO-объектов и их proxy, нам которыми работает некоторая логика, разнесенная по всем частям MVC (по M, V и C соответственно).
Это удобно с точки зрения реализации различных технологий для M, V и C частей приложения соответственно. На выходе имеем M-framefork'и, V-framefork'и и C-framefork'и (иногда наблюдается смешение). В этой парадигме переносить логику в POJO-классы модели, которые отражаются (mapping) на БД, было бы самоубийством.

Какие у нас есть альтернативы?

 

При ответе на данный вопрос всегда необходимо задаться вопросом эволюции ПО. Какая часть системы с наибольшей вероятностью будет меняться, а какая скорее всего останется постоянной?

Будем рассматривать данный вопрос на примерах. Рассмотрим несколько задач, регулярно возникающих в более-менее крупных системах. Причины возникновения данного вида задач выносятся за рамки данного поста, здесь же останавливаемся на реализации.

Обработка данных web-формы

Формы бывают похожие: добавил одно поле, убрал другое, урезали возможные значения до чисел, сделал множественный выбор вместо единственного и т.д. С точки зрения представления — мелкое изменение. Насколько при этом меняется внутренняя логика?

 

Данный пост предлагает решение проблем с использованием перечислений при изменении состава констант или наличия дублирования кода при их использовании. В остальных случаях применение озвученного ниже подхода, как правило, нецелесообразно.

Выкладываю данный пост с целью получения обратной связи от хабра-сообщества Java-программистов. При наличии достаточного количества голосов «за» эту фичу можно будет отправить для рассмотрения в Sun.

Проблема

После длительной работы с Java 5 и Java 6 и небольшой аналитики я пришел к тому, что generic'и в Java имеют ряд ограничений, которые не дают реализовать решение красивым способом, и обходить их порой приходится очень нетривиально. Данное высказывание относится к разработке подсистем, которые активно используют generic'и (доходит до 3-4 generic-типов со сложной иерархией в описании класса).

Приведу примеры кода, которые явно указывают на данные ограничения, а также неудобство использования (рассматривать только синтаксис):

public class A {
    public <X> void method(List<? extends X> list) {
        // processElement(list, list.get(0)); - compilation error
        processElement((List) list, (Object) list.get(0)); // compilation warning
    }

    public <T> void processElement(List<T> list, T object) {
    }

    public static class B<T extends I1 & I2> {
    }

    // Приходится повторять объявления generic-типов
    public static class С<T extends I1 & I2> extends A.B<T> {
    }
}

По ходу подготовки к сертификационному экзамену SCJP, а также при чтении в различных источниках нюансов использования языка Java, возникают множество различных вопросов. Также некоторые особенности языка кажутся совершенно нелогичными, однако так указано в спецификации языка, и каждый уважающий себя профессионал стремится к тому, чтобы знать эти мелочи.

Данный топик посвящен коротким примерам программ (или участков кода). Для каждой программы требуется ответить на простые вопросы: как она будет выполняться и что будет выведено на консоль после ее выполнения. Предполагается использование Java 1.6, если в задаче не указано иное.

Предлагаю вашему вниманию задачку со спичками.
Конечно, тема не нова, так что просьба тем, кто знает решение, не кричать «баян!», т.к. знают, безусловно, не все.

Итак, условие.

Имеются шесть спичек. Требуется составить из них:

• 6 равных правильных треугольников (задача 1).
• 4 равных правильных треугольника, сторона каждого из них равна одной спичке (задача 2).

Остальные условия аналогичны похожим задачам со спичками (нельзя ломать или поджигать спички, нельзя использовать края стола и т.д.)