Перевод статьи LOSING LOOSE COUPLING
Когда меня просят присутствовать на собеседованиях, я обычно задаю один вопрос кандидату: «Что такое хороший код?». Тревожит, что часто можно услышать от недавних выпускников: «Наличие хороших комментариев». Это неправильный ответ. Кто учит их этому? Пугающе. Но я отвлекся… Не думаю, что есть правильный ответ на мой вопрос, однако я бы принял что-нибудь вроде «сильное сцепление (high cohesion) и слабая связанность (loose coupling)». По крайней мере это что-то говорит о коде. Но если это собеседование Java разработчика, я не дам бедняге уйти без нескольких дополнительных вопросов. Потому что Java разработчики полностью обезумели. Они одержимы желанием порубить код на супер-пупер мелкие кусочки. Мы рубим и рубим до тех пор, пока практически ничего не останется. Как только маленькие дорогуши разделены мы начинаем беспокоиться о том, чтобы они не трогали друг друга. Ох, малышки! Мы должны защитить их друг от друга любой ценой. Каждый маленький кусок кода получает свой собственный интерфейс, чтобы он не мог замарать свои руки дотянувшись до других частей напрямую. Мы связываем их магическими фреймворками. Которые используют абстрактные прокси, создающие фабрики и так далее.
Представьте велосипед, сделанный по таким принципам. Рама порублена на кусочки, длиной 1 сантиметр, соединенных по типу позвоночника. Будет ли она более гибкой? Определенно — да. Будет ли она практичной? Конечно, нет. Она будет дороже в производстве в сотни раз. Она также будет ломаться в сотни раз чаще. Такой велосипед приведет к большему количеству несчастных случаев, и не в последнюю очередь, будет странно выглядеть и на нем будет трудно ездить. Наша спина должна быть гибкой, поэтому позвонки имеют смысл. Велосипеды — нет.
Мы не делаем велосипеды из одного куска металла или углепластика. Мы можем поменять колеса, мы можем поменять руль, но мы не сходим с ума по этому поводу. Некоторые части маленькие, некоторые большие и это не плохо.
Еще одна вещь, которую мы делаем при разработке велосипеда — это разработка велосипеда, а не обобщенного (generic) «устройства транспортировки». Мы не пудрим нашим клиентам, о том, что однажды они смогут пересечь на нем Атлантический океан. Если они захотят сделать это, то уж точно не на нашем велосипеде. Если наши клиенты хотят взлететь на крышу небоскреба, мы им мало чем поможем. Это нормально. Мы хотим сделать лучший в мире ВЕЛОСИПЕД. Велосипед, который может быть переконфигурирован в любое транспортное средство и все еще будет хорошо работать может быть опцией для Бэтмена, но, к сожалению, многие из нас не обладают такими бюджетами. Мы хотим, чтобы наши системы были крутыми, соответствовали своему назначению, и мы хотим знать, что мы строим. Гибкость и конфигурируемость для людей, которые не знают, чего хотят, или когда вы хотите, чтобы сторонние поставщики разрабатывали части системы. Производители велосипедных рам точно не ограничивают свои велосипеды только одним типом сиденья, одним типом руля или одним типом колес. В терминах программирования они соединяются с интерфейсом Руль, который может быть реализован любым количеством конкретных моделей рулей. Но рама — это их собственный продукт, который не рубится на маленькие заменяемые фрагменты. Если они захотят делать различные рамы — догадайтесь, что? Они сделают разные модели. Модели используют много общих черт, но они все-таки полностью разные.
В программировании мы преследуем возможность заменять части нашей системы в любыми другими реализациями. Если мы поменяем что-то одно, и это приведет к тому, что что-то другое перестанет работать, то мы видим — это плохой дизайн. Но что произойдет, если мы поставим колеса от монстр-трака на наш велосипед? Велосипед будет работать не очень хорошо, не так ли? Но означает и это, что велосипед плохо спроектирован? В реальном мире мы миримся с тем, что вещи связаны друг с другом («захардкожены», если угодно) мы даже предпочитаем такие вещи. Мы понимаем, для чего эта вешь подходит, а для чего — нет. Велосипеду нужны колеса, которые подходят к его раме. Мы не можем просто использовать интерфейс Колесо мы должны быть достаточно точны. Конструкция велосипеда, к которой можно присоединить любые колеса будет достаточно сложной. Оно не стоит того.
Если мы захотим, чтобы у нашего велосипеда были колеса от монстр-трака, необходимо будет изменить наш дизайн и сделать что-то, чтобы они подходили. И вы знаете что — мы можем это сделать в программировании. Я пришел к этой удивительной технике, не знаю, можно ли сделать то же самое в IntelliJ, но по крайней мере в Eclipse (которым я пользуюсь) вы можете выбрать код, который нуждается в изменении: удерживая клавишу SHIFT нажимая на кнопки курсора до тех пор, пока часть кода, которую надо изменить не будет подсвечена; отпустить клавишу SHIFT и нажать DELETE. И код исчезнет! И тогда вы можете написать что-нибудь другое. Это действительно работает! Я пробовал. В коде Java тоже, не только в xml или properties файлах! Это поразительно!
Когда-нибудь замечали, как большие корпоративные проекты стоят целое состояние, занимают вечность в разработке и потом эффектно проваливаются при попытке получить результат? Существует много причин для этого. Но я убежден одно из них — это гибкость. Гибкость тесака и вакуумного пакета, индивидуально упакованные в мини кусочки обобщенного (generic) кода. Вместо создания (возможно нескольких) систем, которые хороши в специфичных известных случаях мы настаиваем на создании ЕДИНОЙ (супер конфигурируемой) СИСТЕМЫ КОТОРАЯ ВСЕМ УПРАВЛЯЕТ. Программа, которая будет работать для любого, везде, не важно какие у них потребности.
Но что же делать, если однажды нам надо будет изменить базу данных? Что если нам понадобятся эти данные в другом месте? Что если формат этого сообщения изменится? Мы можем это поменять. Не частота ли релизов наших систем стоит на первом месте? Что если мы их изменим? Если наши системы хорошо протестированы и хорошо спроектированы, изменение — это не проблема.
Я за слабую связанность, но сделайте одолжение: убедитесь, что ваше решение связано с вашей проблемой.
Автор: pestell
