При работе в Thunkable X (да и в других средах визуально блочного программирования) наиболее остро чувствуется необходимость использования баланса между удобством работы в IDE, простоте алгоритмов и поддержки проекта. По целому ряду причин удобство работы с проектом и простота алгоритмов находятся на разных чашах весов. Что же выбрать: простоту алгоритмов за счёт удобства работы с проектом или наоборот? Текстовое программирование частично решает задачу, но его оказалось недостаточно, по причине чего на ум пришла концепция полифункционального программирования.
Под полифункциональным программированием мы будем понимать составление алгоритмов при помощи полифункций - блоков функций, которые выполняют разные операции. Постойте, но в текстовом программировании рекомендуется делать функции как можно проще и желательно для выполнения одного простого действия. А здесь получится всё наоборот - создание сложных функции с реализацией множества действий, что затруднит чтение кода, его отладку и поддержку! Да, но реальность такова, что современная концепция текстового программирования имеет немало принципиальных отличий от визуального программирования. Например, в Thunkable X все переменные являются глобальными в пределах экрана и каждый решает сам, является ли это для него принципиальным моментом, не позволяющим использовать данную IDE, или с этим можно работать.
Если сравнивать визуальное программирование с текстовым, то многие скажут, что первое крайне неудобно, а сложные функции сделают это ещё неудобнее. Но в условиях отсутствия в Thunkable X функции копирования блоков между проектами, группового выделения блоков и механизма использования расширений полифункциональные блоки выигрывают в удобстве использования библиотечных алгоритмов. Копирование одного блока с экрана на экран намного проще переноса алгоритма, состоящего из десятков простых функций. Но наша задача состоит не просто в создании полифункциональных блоков, а в создании их максимально простыми в использовании. Иначе в сотнях разноцветных блоках будет чрезвычайно сложно разобраться и данная концепция потеряет смысл и практическую целесообразность.
Рассмотрим для начала общие моменты. В основе структуры полифункциональных блоков лежит блок условного оператора if then, при помощи которого будет происходить выбор нужной операции. Для этого в функцию нужно передать имя операции и другие данные. Они будут передаваться в строке с разделителями, что позволит легко получить из неё список с переменным числом аргументов. Для пояснения того, какие аргументы необходимы той или иной операции, нужно будет создать комментарий. Вместо блоков переменных будет использоваться один глобальный (в пределах экрана) список переменных, что позволит ощутимо сократить количество блоков для работы с данными. В качестве примера создадим полифункцию для работы с ним.
Работа с полифункцией должна происходить максимально простым образом. Для этого в качестве аргумента используется не список, а строка.
CreateList, set и get - это команды. Имена переменных и их значений разделены запятой вместо более понятного и привычного символа равенства с целью упрощения блочного алгоритма работы с ними. Возможно, это усложняет восприятие кода, но в этом нет ничего особенного. Существует огромное количество языков программирования, каждый из которых имеет разную степень сложности восприятия. Сложность визуально блокового программирования растёт в геометрической прогрессии от количества блоков и может получиться так, что увеличение наглядности в одном приведёт к ухудшению наглядности в другом даже в большей степени. Но в нашем случае можно использовать и знак =, если в начало полифункции добавить блок замены всех вхождений = на ,.
Префикс vars. используется для разделения пространства имён. Если имена переменных из библиотечного экрана совпадут с именами переменных на экране пользователя, то это приведёт к необходимости переименования их, чего очень не хотелось бы.
Переменные в списке vars.varList имеют свою область видимости, в которой их уникальность придётся отслеживать самостоятельно. Здесь также можно использовать точечную нотацию.
Определение полифункции показано ниже.
Вначале создаётся список аргументов, затем инициализация переменных и реализация операции выбора действия:
А нельзя ли вместо полифункции использовать для выполнения этих операций блоки для работы со списками? Можно, но тогда при каждой операции с переменными придётся работать с громоздкими блоками set, find, get и др., а благодаря полифункции они собраны в одном блоке, который после отладки можно свернуть и забыть о нём. При использовании полифункций упрощение интерфейса реализовано за счёт усложнения реализации.
Можно ли вместо полифункции использовать блоки для работы с объектами? Можно, но для создания 20 свойств потребуется создать более 40 блоков (с учётом блоков значений), а при помощи полифункции для этого требуется всего 2 блока.
Как воспользоваться данной полифункцией в своём приложении? Для этого вы создаёте свой проект не из пустого проекта по команде Create New App, а из копии библиотечного проекта, содержащего полифункцию. Далее вы дополняете этот шаблонный проект своими экранами и функциональностью. Размер проекта, содержащего библиотеку, увеличится, но зато вы сможете использовать её функциональность без необходимости каждый раз заново создавать из блоков нужный алгоритм.
К сожалению, никто не занимается разработкой таких шаблонных проектов, но на странице загрузки можно скачать проект с кастомизированными компонентами.