Зачем LibreOffice перепутал MVC с FCM и что из этого вышло?

Реальный анализ LibreOffice показывает, что заявленная парадигма FCM, отчасти похожая на MVC, не соответствует фактической архитектуре проекта. Ключевым элементом визуализации является vcl::window, отсутствующий в описании FCM, что подчеркивает конфликт между теорией и практикой. Вместо четкой модели-представления-контроллера, применен иерархический подход, где дочерние визуальные элементы управляются родительскими, формируя древовидную структуру.

В коде LibreOffice, декларативное описание интерфейса (например, тулбара) интерпретируется C++ кодом. Этот код создает дерево объектов, все на основе базового класса vcl::Window. Класс VclBuilder осуществляет преобразование XML-описания в иерархию визуальных компонентов. В итоге получается, что фактически визуальная часть строится на иерархии объектов vcl::window, управляющих дочерними элементами, что совсем не соответствует изначальной идее FCM.

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

Для программирования макросов в LibreOffice, как выясняется, требуется глубокое понимание внутренней структуры, которая отличается от объектной модели VBA. Разработчикам приходится переключаться между моделью, представлением и контроллером, так как нужные свойства и методы могут быть в разных частях FCM. Иногда это вынуждает разработчиков перебирать все элементы коллекции объектов, что усложняет процесс. Применение Python для макросов облегчает задачу, но документации недостаточно, а код остается не самым простым.

Источник: rukhi7