Неверное использование паттерна проектирования «Мост» / «Bridge»

Как это без семантической нагрузки? :-)
На примере визуальных окон.

Window — абстракция окна
WindowPrimitive (у GoF WindowImp) — абстракция ОС-зависимой реализации примитивов для создания окон.
IMNSHO, как раз таки очень понятная семантическая нагрузка.

Неверное использование паттерна проектирования «Мост» / «Bridge»

Основная концепция ООП — снижение сложности ПО.
Если эта цель не достигается — все остальное идет в топку, т.к. с этим становится очень сложно жить.

Неверное использование паттерна проектирования «Мост» / «Bridge»

И еще по поводу множественных иерархий.
Ничто не мешает провести два моста от одной иерархии. И проблемы нет. Паттерн «мост» — это инструмент, абстракция, которую можно использовать — а можно и не использовать, как в Вашем случае. Можно вообще все только на наследовании и агрегации описывать. Только вот паттерны обертывают классы в более понятные структуры, которыми легче оперировать. В результате они снижают сложность восприятия. А, следовательно, с их помощью можно создавать более сложные системы. А без их использования — менее сложные, т.к. у человека есть предел сложности, который он может воспринимать.
Так что, ИМХО, Вы просто не понимаете смысла паттернов, как он описан у GoF. Это не мешает Вам их использовать: вот оно — отличное описание у GoF! Даже те, кто не понимает концепта, может это использовать.

Неверное использование паттерна проектирования «Мост» / «Bridge»

MVC — другая модель с другими целями.
И вообще, паттерны определяются в первую очередь в способом их реализации, а семантикой. К примеру, паттерны «Стратегия» и «Состояние» реализуются одинаково, однако разница в семантике определяет и название, и назначение. Поэтому похожесть структуры на часть MVC — это еще ничего не значит. Семантика другая, назначение и название, соответственно, тоже.

Каждый раз, когда вы выдаете проприетарную фичу за CSS3 — умирает котенок

Если захочет заказчик. Иногда бывает так, что заказчик никогда не посмотрит альтернативные браузеры. И при этом лишать его части пользователей, а также пользователей — возможности комфортно работать с этим сайтом — ИМХО, непрофессионально.

Каждый раз, когда вы выдаете проприетарную фичу за CSS3 — умирает котенок

Разработчики добавят? А Вы уверены, говоря за всех?

Точное вычисление геометрических предикатов

чтобы равные числа были равными

Это относится не только к числам с плавающей точкой.

Субботние записки: О мёртвых языках и живой практике

Думаю, через некоторое время появится язык а-ля SQL для исходного кода, позволяющий искать дубликаты или использование характеных паттернов :-) А также вычленять модули и подсистемы на основе связности классов.

P.S. Ставить прогноз на велечиную этого «некоторого времени» не берусь — очень уж динамично все развивается, и слишком много внешних факторов, не относящихся к программированию как таковому.

Субботние записки: О мёртвых языках и живой практике

Я думаю, на текущем уровне развития пора бы массово задействовать touch-мониторы, и соответственно развивать software для программирования. Я уже давно склоняюсь к тому, что чисто текстовая форма написания программы порождает не только проблемы парсинга, но и holy wars по поводу форматирования. Думаю, JetBrain'овский MPS является попыткой показать это в явной форме.
Программа представляет собой структурированный код, верно? У этого кода есть уровни вложенности, инкапсуляции и т.д. Структуры, описываемые этим кодом, все ближе напоминают семантические сети, которые проще всего описывать графами. Имхо, программирование постепенно к этому и стремится. Соответственно, средства программирования (в т.ч. представление исходного кода программы) тоже рано или поздно поменяет свою форму на более приемлемую.
Не подумайте, что я предлагаю уйти от текстовой формы, нет! Она очень удобна. Но ее внутреннее представление логичнее хранить в виде дерева, а еще лучше — графа со ссылками. Тогда программа сама по себе будет напоминать большой индекс, работа с которым для IDE (а также для тех, кто пишет макросы) будет гораздо проще. А, следовательно, благодаря упрощению одного из элементов цепи поддержки работы, появится возможность создания более продвинутых средств программрования.
Т.е. все как обычно. Автоматизируем все, что можем представить, как это можно автоматизировать, и оставляем для мозгов действительно сложные задачи, требующие творчества.

Субботние записки: О мёртвых языках и живой практике

Возможно для того, чтобы форсировать написание кода «с нуля».

Проблемы инкапсуляции

Читал все :-)
ИМХО, гораздо понятнее и интереснее фильма.

Swing. Десять полезных простых вещей

Лучше наоборот, не находите?

public Component getTableCellEditorComponent(JTable a, Object b, boolean c, int row, int column) {
    selectedRow = row;
    selectedColumn = column;
    setFocusable(false);
    return this;
}

Искусство программирования?

Программист = инженер.
Аргументацию — «Профессиональная разработка программного обеспечения», Стив Макконнелл.

Искусство программирования?

Давайте проясним: заниматься наукой — это значит искать новые знания.
Работа инженера — это использование этих знаний для практических целей.
Знать достижения науки нужно и тем, и другим. Однако используют они их по-разному.

Искусство программирования?

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

Искусство программирования?

Можно более-менее автоматизировать создание блоков кода, выполняющих определенные задачи. У меня есть смутное понимание, что это возможно на текущем этапе развития IT, требуется только время, деньги и желание.
А вот создать их таким образом, чтобы они были понятны человеку — вот это настоящая проблема.

Искусство программирования?

Вы не правы, банальный пример: выбор адекватных имен переменных и методов.
В ближайшем обозримом будущем не предвидится способов автоматизировать этот процесс — раз, и даже правильные имена у разных людей могут быть разные. А имена тянут за собой интуитивную логику. А логика тянет за собой структуру кода реализации.
В итоге у разных разработчиков получится разный код, по-разному структурированный. И с разными плюсами и минусами в пределах допустимых значений. В зависимости и от личных предпочтений, и от задачи.

Swing. Десять полезных простых вещей

    public Component getTableCellEditorComponent(JTable a, Object b, boolean c, int d, int e) {
        selectedRow = row;
        selectedColumn = column;
        setFocusable(false);
        return this;
    }

IMHO, компилироваться не будет :-)

Будни программиста или редкий случай ошибки в компиляторе

Более того, для set-методов одинаковые имена даже удобны:

public void setValue(int value) {
    this.value = value;
}

Apple планирует защищать свою продукцию от краж хранением пароля в зарядном устройстве

Да, а как насчет кражи пароля? :-)
Т.е. под невинным предлогом просим подзарядить телефон, а сами при этом тырим пароль с зарядки.

Выглядит как доп. возможность для соц. инженерии.