Утрата слабой связанности

Интересно, как будет выглядеть велосипедная рама, если проектировщик ожидает (и по опыту уверен) что любая самая неожиданная деталь этой рамы может измениться во время проектировки или, что бывает гораздо чаще, непосредственного производства. И без учёта времени на доработку и бюджета.

На лицо попытка доказательства по аналогии с объектом реального мира. По умолчанию все такие аналогии надо считать лживыми.

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

Мысли правильные, аргументация — неочень.

Актуальная статья. Иногда кажется, что некоторые программисты пишут код ради самого кода.

Всегда умиляла любовь людей из мира CS/IT к аналогиям и метафорам. Если забыл умные слова или не можешь привести конкретный пример, сделай мудрое лицо и расскажи про яблочки велосипеды.

Плохой выбор метафоры.

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

По существу вопроса. Насчет Java. Я лично программирую в основном на Scala и JavaScript. Мне нравится и Java, но мне кажется, проблема модели «сильное сцепление и слабая связанность» в том, что на Java она стоит слишком уж дорого по сегодняшним меркам. Очень много кода приходится писать, чтобы ее поддерживать. Опять же система зависимостей Maven/Ant(кстати, и SBT тоже) довольно громоздкая, и там довольно тяжело поддерживать большое количество микромодулей. Много обслуживать приходится. Скажем, если сравнивать с тем же NPM для Node.JS, то учитывая все плюсы и минусы Ноды, нельзя не признать, что на практике низкий порог для публикации модулей сыграл важную роль в развитии системы модулей. Системы из микромодулей со слабой связанностью на Node/NPM собирать гораздо легче, чем на том же Java.

Вспомнил про фабрики по производству фабрик молотков.

Для меня лично, всплывают ассоциации между GNU Hard и Linux

иногда это приводит к AbstractSingletonProxyFactoryBean

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

Если уж автор приводит аналогию велосипеда — а велосипедной рамы, как некоего неделимого модуля системы, которые выполняет свою функцию надо иметь ввиду следующее:

1) рама — несущий элемент, ответсвенный, а значит дробление его на мелкие части повышает вероятность отказа или поломки.
2) рамы бывают разные, форма у них похожа, однако рамы не взаимозаменяемы (интерфейсы каретки, рулевой колонки, подседельной трубы разные)
3) если пользователю нужно получить наиболее надежный и целесосбразный вариант — реализация рамы делается под конкретного пользователя (карбон, титан и т.п.)
4) именно рама задает практически все свойства велосипеда.

Исторически сложилось, что рама хардтейла получила один съемный элемент — петух заднего переключателя — и то, для повышения ремонтопригодности и даже не на всех рамах этого типа он есть.

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

Модуляризовать ради того, чтобы просто получить кучу модулей — раньше времени увеличить сложность продукта. Создать кучу интерфейсов, применить кучу паттернов просто так? Сложность (а соответственно и стоимость разработки) должна возрастать с ростом полезности, ведь так?

По сравнению создания программных продуктов с проектами в реальном мире есть хорошая метафора:
«Почему постройка домов никогда не затягивается по срокам так, как создание программного обеспечения? Потому что после построения дома заказчик не может сказать: „А теперь я хочу, что бы лифт ездил не только между этажами, а еще и внутри этажа, развозя корреспонденцию по отделам“»
В этом и основная проблема — в IT требования к продукту постоянно меняются, и хорошая архитектура должна давать возможность реализовывать эти требования без необходимости разбирать дом до кирпичика и строить всё заново.

Аналогия велосипеда и программного совершенно не корректна. Да железная рама должна быть прочной из единого куска алюминия. Но программный код не должен быть монолитным чтобы быть надежным

Термин «велосипед» явно выбран неудачно, лучше бы машина или чтото похожее.

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

не понимаю, что все к этому «loose coupling» так мм… прицепились ;). вот если бы автор еще и «high cohesion» так же красочно расписал, то половины интриги могло не получиться — как раз этот принцип не дает совершать всякие глупости. как то крошить код без надобности, или пилить рамы лисапедов на кусочки длиной 1см. в теории конечно: принципы-принципами, — они не мешают делать на практике весьма причудливые вещи.

Хорощий код — это тот код, который решает задачи проекта при наименьшей стоимости реализации и поддержки.

Согласен с положениями в статье, но не согласен с примером. Пример специально подведен к космическому построению архитектуры.
Например: требуется велосипед. К велосипеду есть определенный набор требований, и мы их реализуем. Именно по факту требований. Нужно что-то больше? Появляются новые требования. Из-за них могут появиться первые или новые уровни абстракции, опять же в угоду требованиям, но мы не пишем всё заново.

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

Ещё один момент: фреймворки. Они для того и нужны, что позволяют построить каркас. Но они ни разу не завязаны на требованиях к конкретной области, поэтому и стараются максимально декомпозироваться на модули. А вы уже выбираете: вам один позвонок или всё-таки позвоночник.

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

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