Допустим, перед вами встала задача по выполнению JavaScript кода в C++ приложении. Например есть набор выходных данный или переменных, названия которых заранее известны, а также имеются куски JavaScript кода, который что-то делает с этими переменными. Причём ещё имеется алгоритм, который при наличии каких-либо условий будет выбирать. какой именно JavaScript код следует запускать.

Также, вы не можете просто взять и переписать тот JavaScript код на C++ код и хардкорно добавить его в приложение. Поскольку таких кусков кода очень много, при этом их обслуживанием занимаются другие люди и постоянно добавляют новые кусочки кода.

То есть в данном случае набор входных данных и JavaScript код для нас является данными, в некотором роде контентом, который мы запускаем в работу с помощью определённого алгоритма, по которому выбираем, при каких условиях для одного и того же набора входных переменных выбирать тот или иной кусок JavaScript кода.

Надеюсь, что я понятно объяснил, почему нам нужно запускать выполнение JavaScript кода в C++ приложении.

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

Также добавим поле ввода TextEdit для написания JavaScript кода, который мы будем выполнять в нашем приложении.

И последнее поле ввода будет называться Result (это будет TextEdit), которое будет отвечать за вывод новых посчитанных значений введённых нами переменных.

Также добавим QPushButton, который будет запускать выполнение JavaScript кода.

Приложение будет выглядеть так, как на рисунке ниже.

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

Всегда было интересно, действительно ли ускоряется сборка при использовании директивы #pragma once , вместо классического #ifndef #define #endif.

Проверить это ускорение на маленьком проекте довольно проблематично, ведь если проект собирается в среднем за 20 секунд, то и ощутимого ускорения мы скорее всего не увидим, поскольку длительность сборки всегда будет плавать от 17 до 23 секунд.

Но у меня выдалось свободное время и удалось проверить эту теорию на крупном проекте.

На форуме возник вопрос, как создать динамическую библиотеку и правильно её подключить в сторонний проект. Периодически такие вопросы возникают, поэтому рассмотрим один вариант создание динамической библиотеки dll для Windows с использованием визардов стандартных в Qt Creator.

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

Создадим два проекта:

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

Цели

• Использование общего доступа для эффективного использования большого количества объектов.
  
• Стратегия GUI Motif по замене тяжеловесных виджетов легкими виджетами.
  

Проблематика

Проектирование объектов вплоть до самых низких уровней «гранулярности» системы обеспечивает оптимальную гибкость, но может быть неприемлемо дорогим с точки зрения производительности и использования памяти.

Цели

• Предоставить унифицированный интерфейс для набора интерфейсов в подсистеме. Фасад определяет интерфейс более высокого уровня, который упрощает использование подсистемы.
  
• Обернуть сложную подсистему более простым интерфейсом.
  

Проблематика

Для сегмента клиентского доступа требуется упрощенный интерфейс для доступа к общей функциональности сложной подсистемы.

Пример шаблона проектирования Объектный пул на языке программирования Python.

Пример шаблона проектирования Объектный пул на языке программирования Java.

Пример шаблона проектирования Объектный пул на языке программирования C++.

Цели

• Добавить дополнительные возможности и функционал к объекту динамически. Декораторы обеспечивают гибкую альтернативу подклассу для расширения функциональности.
  
• Указанное клиентом декорирование интерфейса основного объекта путем его рекурсивной упаковки.
  
• Оберните подарок, положите его в коробку и оберните коробку.
  

Проблематика

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

В шаблоне Factory Method, фабричный метод определяет, какие функции должны быть доступны не абстрактной конкретной фабрике. Эти функции должны иметь возможность создавать объекты, которые являются расширениями определенного класса. Какой именно подкласс создается, будет зависеть от значения параметра, переданного функции.

В этом примере у нас есть фабричный метод AbstractFactoryMethod , который реализует функцию makePHPBook($param)

Конкретный класс OReillyFactoryMethod factory расширяет класс AbstractFactoryMethod и может создать правильное расширение класса AbstractPHPBook для заданного значения $param.