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

Когда-то. Давно. Мы силами нашей большой и дружной команды написали ОФИГЕННЫЙ (как нам тогда казалось) фреймворк для "конструирования" 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'ы. И "вызов метода по селектору". И от всех их отказались (точнее - "почти от всех"... "утиную" типизацию - например ПОКА - сохранили). "Почему-то".. Ну я то - знаю почему...