вторник, ноября 06, 2007

В плену правильных идей

Мы живем и работаем в плену стереотипов. Все мы знаем как делать "правильные приложения". Слои, уровни, шаблоны проектирования... Вот, например:
"В бизнес логике выделяем слой интерфейсов. Объявление отделяем от имплементации. Вводим фабрику интерфейсов. Назначение конкретной имплементации описываем в специальной секции конфигурационного файла."

Вполне здравые идеи, и звучат убедительно, как будто кто-то гвозди в доску забивает. Малую малость упустили из виду - "А зачем это все?" Смотрим в исходники проекта, и видим что? Для каждого интерфейса на весь проект только одна реализация, альтернатив нет и не предвидилось. "Специальная секция конфигурационного файла" не разу не изменялась с момента своего создания. Так и зачем огород городить было?

Или другой пример. Надо построить квартальный отчет по продажам, и для этого используем класс Sale, экземпляры которого, представляют продажи в бизнес логике приложения. За квартал набегает пара десятков тысяч продаж, и естественно, сервер приложений ложится на вычислении квартального отчета. Хранимая процедура в БД справилась бы с этой работой за несколько секунд, но "архитектура системы запрещает обращения к БД из слоя бизнес логики". К счастью догматы архитектурной веры позволили создать в системе бизнес объект "Квартальный отчет по продажам", который по всем архитектурным правилам, посредством DAL, и с прочими приседаниями, получил данные из шустрой хранимой процедуры, и таким образом, весь сервер приложений был спасен от неминуемой гибели.

Мораль. Не давайте шаблонам управлять своими мозгами. Должно быть все наоборот. Оставайтесь в меру беспринципными, когда это может пойти на пользу делу. И главное: "Do simplest thing that could possibly work" (с)К. Бек.

10 комментариев:

Анонимный комментирует...

"Смотрим в исходники проекта, и видим что? Для каждого интерфейса на весь проект только одна реализация, альтернатив нет и не предвидилось."

Традиционное решение проблем, которые скорее всего никогда не возникнут. А слой абстракции от БД у вас предусмотрен? Ну на тот случай если придется преходить с MsSql на Oracle? :)

Явление описанное вами давно имеет название - дизайнэнурез или недержание креатива.

Sergey Rozovik комментирует...

>"недержание креатива"

Это надо запомнить. :)

Анонимный комментирует...

шаблоны тут не причем
просто надо кроме шаблонов еще и мозги использовать

Анонимный комментирует...

с основной идеей согласен - нехорошо быть в плену, даже у правильных идей :)

по поводу обложиться интерфейсами - это ведь хорошо для юнит-тестирования (моки, фэйки, стабы и т.п.)

видимо, тут можно придумать какое-то мнемоническое правило насчёт интерфейсов - обложиться интерфейсами, но не облажаться :)

Iv комментирует...

keep it simple stupid :)

Но ведь лучше, когда выделенный слой, когда все обложено интерфейсами, ведь когда возникла проблема, мы можем в конкретном месте, в конкретное время, обойти какой-нибудь слой, повесить атрибут [PerfomanceHack] и сервер приложений снова оживает, а вот если у нас на самой странице, код в PageLoad() создает конекшен, потом ломится в базу и так во всем приложениее :), то тут все гораздо сложнее. Правильно написанную программу гораздо легче оптимизировать при необходимости, чем криво написанную.

Sergey Rozovik комментирует...

> Но ведь лучше, когда выделенный слой, когда все обложено интерфейсами

Любое пректное решение должно приниматься осмысленно. Мы привыкаем "выделять слой доступа к данным, слой бизнес логики..." и т.д. просто потому, что делаем это всегда. А ведь это - проектные решения, и они были в свое время придуманы для решения совершенно определенных проблем и задач. Всегда сказав "а", говори "б". Сказав "мы выделяем слой ...", говори самому себе "для того, чтобы...".

Анонимный комментирует...

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

Анонимный комментирует...

Судя по всему, мало кто понимает, для чего же нужна эта волокита с интерфейсами, слоями и шаблонами. А нужна она для того, чтобы поддерживать балланс между связностью и зацеплением компонентов. Необходимо обеспечить гибкость сохранив простоту. Все это необходимо для того, чтобы облегчить разработку. ОБЛЕГЧИТЬ! А не запутать и не затруднить. Поэтому каждый интерфейс, который был реализован только один раз - это очередной гвоздик в крышку гроба проекта. Когда их единицы, это не страшно. Но когда их десятки, то на код можно смело вешать атрибут [kg/am].

Илья Казначеев комментирует...

http://alamar.livejournal.com/178410.html
Проблема, на самом деле, возникает не от излишне правильного разделения слоёв, а оттого, что когда в руке один большой молоток, шурупы и саморезы имеют все шансы быть забитыми.

А именно: у программистов корпоративных систем есть привычка всё писать на одном языке, не считая XML. То есть, на Java/C#.

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

На самом же деле, бизнес-логику писать надо на некотором миниязыке, который будет предназначен именно для манипулирования массой бизнес-объектов. Этот язык будет позволять описать то же построение квартального отчета в десять раз короче.

И, самое важное, этот язык будет одинаково прозрачно компилироваться хоть в Java+EJB, хоть в PL/SQL. Из одного и того же исходника. При этом будучи языком высокого уровня и работая исключительно на уровне бизнес-объектов.

Анонимный комментирует...

ну вот, сами Люксы (известные как Великие Собеседователи) себе противоречат.

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

вот реально, где, в каком корпоративном приложении используются все эти Айоки, ТДД, моки, распределения обязанностей?

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

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

опять же оговорюсь - в большинстве случаев. разумеется, есть такие фрагменты и компоненты систем, где это все применяется. но применять надо по делу, а то получится стрельба из пушки по воробьям.

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