понедельник, 16 сентября 2013 г.

О собственных фреймворках

Когда-то. Давно. Мы силами нашей большой и дружной команды написали ОФИГЕННЫЙ (как нам тогда казалось) фреймворк для "конструирования" GUI-приложений. Скажем так "Office & IDE like".

Построенный на Delphi и VCL.

Называется VCM.

Вам не почудилось.. "Похоже" на MVC...

Именно. "Акроним" - взят оттуда. Да и разрабатывали мы свой фреймворк "с оглядкой на MVC".

Хотя мы тогда сами его не до конца понимали.

В итоге получилось "нечто" похожее на MVC, но в "своей интерпретации". И с гораздо большим количеством "слоёв ответственностей".

Что он позволяет?

А вот что:
- Описывать "модель данных", опирающуюся на объекты "БД".
- Описывать модель бизнес-объектов "областей ввода", опирающуюся на "модель данных".
- Описывать сущности (группы операций) и операции внутри них.
- Описывать "области ввода". Опирающиеся на "бизнес-объекты областей ввода" и сущности с их операциями. В терминах VCL - "формы". И РЕАЛИЗУЮЩИЕ "сущности" и "операции".
- Описывать бизнес-объекты "прецедентов. Опирающиеся на бизнес-объекты "областей ввода".
- Описывать "реализации прецедентов", опирающиеся на бизнес-объекты-прецедентов и "области ввода".
- Ещё несколько аспектов, которые "с кандачка" не опишешь.

Далее фреймворк позволяет конструировать приложения на основе уже описанных прецедентов.

Отдельно он строит "фабрики прецедентов", для создания экземпляров "реализаций прецедентов". А также "фабрики областей ввода", для создания "экземпляров областей ввода".

Кроме этого он позволяет в РЕАЛЬНОМ ВРЕМЕНИ строить командные меню, тулбары и контекстные меню. Для текущего экземпляра "реализации прецедента". Опираясь на описания сущностей и их операций.

Все отношения между указанными "элементами системы" описывались формальными правилами (предикатами - если хотите).

И всё было КРАЙНЕ ЗДОРОВО. Версия 1.0 фреймворка с точки зрения "реального программиста", живущего в "идеальном" мире - была - "ИДЕАЛЬНА". Она была - Perfert (если хотите).

И мы на этом фреймворке много чего сделали.

Но потом - "семейная лодка разбилась о быт".

О какой - спросите вы.

Да вот о какой - мы встретились с "реальными заказчиками" и "реальными дизайнерами".

И тут наши "ИДЕАЛЬНЫЕ" формальные правила полетели в тартарары.

Заказчики и дизайнеры - живут в ДРУГОМ мире. Они - "не понимают", да и "не хотят понимать" формальных правил "реальных программистов", живущих в "идеальном" мире.

Да и в общем-то - они - ПРАВЫ.

И началось - "а давайте тут красную ленточку.. а тут синюю кнопочку... а тут пункт меню убрать.. а тут пункт меню прибавить.. а тут сдвинуть на три пикселя..." И всё в таком духе....

И вся наша "идеальная" концепция - разлетелась как карточный домик.

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

И были версии фреймворка - 2.0 и 3.0. И они были - ОТНЮДЬ не "идеальны", с точки зрения "реального программиста", живущего в "идеальном мире".

Заказчикам и дизайнерам - НЕ НУЖНА, да и "непонятна" формальная логика предикатов. Они хотят - "красную ленточку и на три пикселя влево".. И - ИМЕЮТ ПРАВО!

Они живут в "реальном", а не "идеальном" мире. И именно они - ОТВЕТСТВЕННЫЕ за то, чтобы "продать" систему и "реальные программисты" - получили свою зарплату. Я нарочно утрирую.. Конечно...

К чему это я?

К ТОМУ, ЧТОБЫ НЕ ПИСАТЬ СОБСТВЕННЫХ ФРЕЙМВОРКОВ?

Нет КОНЕЧНО!

ПИСАТЬ!

Особенно если вы задумываетесь о "повторном использовании" уже "обкатанных" ПРОЕКТНЫХ РЕШЕНИЙ.

ПИСАТЬ!

Но!

Надо быть готовым к тому, что придёт "реальный заказчик" или дизайнер. И начнёт "ломать" всё вашу "идеальную схему".

И НЕ НАДО воспринимать это как "личную обиду" или "плевок в душу".

Мир "реальных программистов" и дизайнеров - ПО-ДРУГОМУ устроен. Они - ПО-ДРУГОМУ видят.

И имеют на это ПОЛНОЕ ПРАВО.

Особенно, если ОТВЕЧАЮТ за ПОСЛЕДСТВИЯ своих решений.

И ещё... Чем хорош "собственный фреймворк" в такой ситуации? Да ТЕМ, что вы можете - ЕГО ИЗМЕНИТЬ и ПОПРАВИТЬ. А чужой - вот уж дудки. Тут придётся сказать заказчикам - "архитектура - не позволяет сделать вашу "красную ленточку""...

Ну как-то  так...

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

P.P.S. Кстати в этой разработке мы использовали многие "новомодные" технологии. И "утиную" типизацию. И "открытые именованные списки параметров". И fluent-interface'ы. И "вызов метода по селектору". И от всех их отказались (точнее - "почти от всех"... "утиную" типизацию - например ПОКА - сохранили). "Почему-то".. Ну я то - знаю почему...

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

  1. Для Python И PyQT подобное - было бы конечно интересно если кто-нибудь реализовал бы :-)

    ОтветитьУдалить
  2. Прошу уточнений.
    Если MVC полностью отделял модель от вью, то, походу, можно было в модели как угодно навязывать ленточек и бантиков, смещая их практически на 1,5 пикселя влево.

    Можно какой-нибудь пример?
    >>- Описывать "области ввода". Опирающиеся на "бизнес-объекты областей ввода" и сущности с их операциями. В терминах VCL - "формы". И РЕАЛИЗУЮЩИЕ "сущности" и "операции".

    Косяк (извините) был где-то тут? :)
    Списочное свойство, к примеру, выбиралось из лист-бокса, тогда как дизайнеры потребовали комбо-бокс? И тогда "отрезанная" от интерфейса предметно-ориентированная база в прикладных терминах/сущностях начала нагружаться признаками из разяряда "как оно должно выглядеть"?

    - Отделима ли душа от тела?
    - Отделима ли модель данных от интерфейса?

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

    Я просто столкнулся с тем, что пользователь НЕ ДУМАЕТ в терминах предметной области (еще раз внимательно). Пользователь уже сделал скачок в сознании и проецирует реальную жизнь на кнопки-списки-тулбары, а не на абстрагированную (ща скажу - НЕ натуральную) модель данных?

    Такая вот блин "инкапсуляция" модели в оболочку из интерфейса. Гы-гы.

    ОтветитьУдалить
    Ответы
    1. "Списочное свойство, к примеру, выбиралось из лист-бокса, тогда как дизайнеры потребовали комбо-бокс?"

      -- вы АБСОЛЮТНО правы. Один из ПЕРВЫХ косяков лежал именно в этой плоскости.

      Удалить
    2. "Я просто столкнулся с тем, что пользователь НЕ ДУМАЕТ в терминах предметной области (еще раз внимательно). Пользователь уже сделал скачок в сознании и проецирует реальную жизнь на кнопки-списки-тулбары, а не на абстрагированную (ща скажу - НЕ натуральную) модель данных?"

      -- это похоже на правду.

      Удалить
    3. "Можно ли констатировать провал MVC (не, не Ваш, обще-человеческий) как то, что никакая модель данных не является полезной вне контекста интерфейсного интерфейса (думаю, Вы поняли, о чем я)."

      -- не стал бы говорить так "резко".

      Удалить
    4. "Можно какой-нибудь пример?"

      -- пример чего именно? Провала?

      Удалить
    5. "- Отделима ли душа от тела?
      - Отделима ли модель данных от интерфейса?"

      -- я - оптимист. Пока я верю в это.

      Удалить
    6. "Если MVC полностью отделял модель от вью, то, походу, можно было в модели как угодно навязывать ленточек и бантиков, смещая их практически на 1,5 пикселя влево. "

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

      Удалить
    7. "Такая вот блин "инкапсуляция" модели в оболочку из интерфейса. Гы-гы."
      -- я давно склоняюсь к тому, что надо не только "описывать какую задачу решаем", но и "рисовать экраны". СРАЗУ.

      А потом "экраны" сводить к тому "какую задачу решаем". И искать противоречия. Ну или попадания в точку.

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

      Удалить
    9. Дополнение.

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

      Удалить
    10. "Можно ли констатировать провал MVC"

      -- САМА идея - по-моему - неплоха. Но не в исполнении Apple. Других исполнений я, к сожалению, детально не знаю.

      Знаю - "своё". Но это далеко уже не MVC. Да и там - "вопросов" - БОЛЬШЕ, чем ответов.

      Удалить