Модули инкапсулируют мировое зло (design pattern «отвязный код»)

Лирическое отступление

Дизайнеры (не «конструкторы», а обычные, рекламные), по моим наблюдениям, делятся на две части: на тех, кто идёт «от материала», и на тех, кто идёт от идеи. Последние обычно имеют художественное образование (или мышление); они сначала создают идею для решения задачи, а потом ищут средства для её воплощения. Ещё одна общая черта: бегло ознакомившись с набором «фильтров» Фотошопа, они отбрасывают их и предпочитают воссоздавать все описанные эффекты руками.

В прошлом веке мне довелось работать вместе с одним из дизайнеров, относящихся к первой группе («от материала»). Он не был профессионалом в искусстве, но был хорошим компьютерщиком. Ознакомившись со всеми эффектами и возможностями Фотошопа, он выбрал Корел – там возможностей оказалось больше, а воплощать их – совсем легко. Принцип работы был такой: порыться во всех текстурах, градиентах, «эффектах» и скомбинировать что-нибудь «крутое» и пёстрое («живенько так»). А если заказчик просил вариант («этот угол посветлее, а вот эту надпись пожирнее»), на первоначальный эскиз сверху накладывался слой («высветляющий», или «редактирующий», или искажающий...). Слоёв таких накапливалось обычно не один десяток.

Технология обеспечивала «воспроизводимость» творения на уровне любого слоя. Только вот потом напечатать на postscript такое творение было невозможно (не прожёвывались нормально все эти «прозрачности» и «экструды»). Приходилось экспортировать это чудо в битмап.

Проблема веба не в mvc

В последние годы появилась ещё одна тема для «священных войн» – о шаблоне проектирования mvc в веб-программировании (есть он там или нет, и какую пользу приносит). С учётом того, что mvc ещё и часто смешивают с ООП, войны ведутся совершенно бессистемно. Между тем, есть один простой факт (отчасти послуживший основой для войн), он обычно явно или неявно признаётся всеми сторонами: веб-программирование усложнилось, и усложнилось оно за счёт внедрения ООП (независимо оттого, насколько полно там реализуется mvc).

Странно, что ни у кого не возникает вопрос: «Почему?» А может, и не странно, если вспомнить один из вариантов этого вопроса: «Qui prodest?» («Кому выгодно?»). В статье Распознавание design pattern «модель – контроллер – представление» в Вебе мы обратили внимание на то, что в создании и эксплуатации сайта пересекаются интересы нескольких участников (системного администратора, программиста, автора, пользователя...). Кто из них может получить пользу, оттого что код занимает мегабайты и немерено тратит ресурсы?

Ясно, что это может быть только программист. Объём кода растёт по определённой причине. Главный «шаблон», который давит на программиста, вовсе не mvc, а «шаблон несвязанного кода» (или «шаблон модульности»). Связанность Представления с Логикой или с Логики с Данными остаётся абстракцией, пока не возникнет необходимость воспроизвести какую-то функцию программы на другом сайте, с другим окружением. А когда такая необходимость возникает, программист обнаруживает, что связаны не какие-то там абстрактные «слои», а конкретные методы какого-нибудь одного небольшого объекта, впавшего в рабскую зависимость от другого объекта.

Вот это и является главной движущей силой прогресса в уме программиста – желание избавить участок своего любимого кода от рабской зависимости. Создать модуль.

Пили, но знай меру

Но почему же модульность – зло? 1) Злом может стать любой «плохой шаблон» («анти-паттерн»); 2) «гипер-модульность» является не просто плохим шаблоном, а Мировым Злом.

Когда программист улучшает программу, в которой вообще не было «разделения труда», – это безусловный прогресс. О чём тут спорить: и Данные надо отделять от Представления, и мелкие функции программы стараться изолировать друг от друга. Но до какой степени? Как узнать, где предел этому делению? Что заставит программиста остановиться и «денормализовать» обратно часть кода? – да ничего! В том и проблема, что у «паттерна модульности» нет естественных тормозов в контексте разработки (они появляются позже, когда «железо» перестаёт справляться...).

Это радикально меняет мышление разработчика. Теперь, если добавится какой-нибудь необычный объект (например... ну, «покупатель», не желающий переходить с XP на «Семёрку» – ведь вся их сраная «бизнес»-логика строится на делении мира на продавцов и покупателей!), что делать с объектом «обычный покупатель»? Добавить ему новое свойство «у, бар-ран!» нельзя, потому что для получения к нему доступа надо будет менять также и интерфейс, через который объект общается с другими объектами. А тогда придётся менять ряд других объектов!

Проще (дешевле!) создать рядом ещё один объект-заплатку «патч странности для объекта Покупатель». А потом ещё один... (Узнаёте шаблон «наслоение», описанный в первой части статьи?) В результате не только веб – и прикладные программы, и ОСы наращивают от версии к версии объём и потребляемые ресуры в режиме «дурной бесконечности». Потому что это дешевле – всё максимально «инкапсулировать», формализовать и поставить труд программиста на конвейер. За рутинный труд и платить можно меньше, и менять недовольных проще.

Ещё желательно заклеймить позором тех, кто хочет всё-таки что-то понять, научиться мыслить самостоятельно. Например, с помощью ярлыка «анти-паттерн велосипед». Между тем, «велосипед» принципиально не может быть «плохим шаблоном». Даже «одноколёсный». Изобретая его, программист наносит вред только себе одному (программу с «плохими» шаблонами ведь никто не купит «на экспорт»!); но польза, которую он при этом получит, всегда будет неизмеримо превосходить вред.

Не потому что ошибки полезны для учения, нет. А потому что человек, который самостоятельно изобрёл «велосипед», является потенциальным изобретателем электромобиля. Что ж, зато человек, который велосипед скопировал, научился мудрому закону рисования Вуда: «Никогда не рисуйте то, что можно скопировать». Его ждут большие перспективы в плане карьерного роста. А изобретатели постепенно вымрут. Что, собственно, и требуется таким фирмам, как Микрософт, Адоб и 1С.

D.M., admin

Читать все комментарии (0)