Рубрика «декларативное программирование» - 2

    В Caché есть несколько различных способов пройтись по коллекции и выполнить какие-нибудь действия с ее элементами. Самым простым является while-цикл. Такой способ позволяет решить поставленную задачу в императивном стиле. Разработчику приходиться явно заботиться об итераторе, о переходе к следующему элементу и о проверке выхода за пределы коллекции.
    Но разве это то, о чем должен заботиться разработчик?! Разработчик должен решать поставленную перед ним задачу, за максимально короткое время с максимально хорошим качеством кода. Было бы очень здорово просто взять коллекцию и применить к ней функцию, которая выполняет необходимые действия на каждом элементе этой коллекции. Не проверять границ, не создавать итератор, не вызывать вручную функцию на каждом элементе. Такой способ решения задач называется декларативным программированием.

Declarative programming is when you write your code in such a way that it describes what you want to do, and not how you want to do it.

(c) 1800-information
Давайте подумаем, как же решить поставленную задачу декларативно, используя средства и возможности Caché.Читать полностью »

Приручаем ZoG (Часть 4: Осторожно — мины!)Сегодня я хочу продолжить рассказ о возможностях языка описания игр ZRF, используемого Zillions of Games. В предыдущих статьях цикла я показал как описываются ходы фигур, но есть еще одна важная разновидность хода, оставшаяся не рассмотренной. Помимо перемещения фигур по доске (возможно со взятием фигур противника), игрок (если ему это разрешено), может добавлять новые фигуры на поле. Эта разновидность хода называется сбросом (drops).
Кроме того, в сегодняшней статье, я расскажу о том, как в ZoG осуществляется генерация случайных ходов. Этот функционал необходим, например, при реализации игр, использующих броски игровых костей, для выполнения ходов, таких как Ludo или Chaturanga.

В качестве примера, я предлагаю, взяв за основу классические Шахматы, реализовать игру по мотивам одной из миссий сюжетной кампании Battle vs Chess. Большинство миссий в кампании играются по измененным правилам. Миссии различаются по сложности, в некоторых, для победы, достаточно провести одну из пешек в ферзи, в других — поставить мат за ограниченное число ходов. Я предлагаю рассмотреть четвертую миссию кампании Хаоса под названием «Точка невозврата».
Читать полностью »

Волки и Козленок В предыдущей статье я рассказывал об уникальном, на мой взгляд, проекте Zillions of Games. Как я и обещал, я начинаю небольшой цикл учебных статей по описанию возможностей декларативного языка, предназначенного для разработки новых (и описания уже существующих) игр, в рамках этого проекта.

Для того чтобы не загромождать изложение излишними (на этом этапе) подробностями, я выбрал для реализации очень простую игру. Я играл в нее в детстве. Она называется «Волки и Козленок». Правила следующие: Волки (черные фигуры) — ходят на одну клетку по диагонали, только вперед. Козленок (белая фигура) — также ходит на одну клетку по диагонали, но в любую сторону. Задача белых — пройти на любую из четырех клеток своего цвета последней горизонтали. Задача черных — лишить белых возможности хода.

Поскольку на стандартной шахматной доске 8x8 черные побеждают элементарно, используем для игры доску 9x9 клеток. Эта игра очень простая (и нравится детям). При правильной игре, белые всегда побеждают.
Читать полностью »

Работа с QML Canvas В последнее время на хабре было много хороших постов, раскрывающих аспекты работы с QML: XMLHTTPRequest, Loader, GLSL, но до сих пор никто не упоминал, что Qt Quick 2.0 содержит также компонент Canvas, который даёт нам возможность (сюрприз!) рисовать. Синтаксис использования тот же, что и у HTML5 Canvas, но лично мне, как человеку, далекому от разработки для веба, это ни о чём не говорило.
Продемонстрировать работу с ним я хочу на примере создания каркаса для игры, который, при желании, легко можно будет переделать либо в старую добрую Snake, либо во что-то вроде Achtung, die Kurve!Читать полностью »

Хотел бы начать тему о недостатках декларативного подхода с простого примера – процедуры валидации.

Во многих системах (в большинстве?) валидаторы различных бизнес-объектов задаются в декларативном стиле – в виде атрибутов, XML конфигураций и др. Иногда валидаторы генерируются автоматически на основе структуры базы данных (длинны колонок например) и т.д.

Насколько оправдан декларативный подход когда мы задаем валидацию, насколько он удобен? Я предлагаю рассмотреть сложный случай, когда разрабатывается, например, B2Bсистема и каждый клиент, подключенный к системе, может в некоторых случаях иметь разные настройки валидации. Кроме того, предположим, что разработка ведется в команде в параллельных бранчах и нам нужно периодически объединять (merge) их. Да, и еще система предполагает локализацию валидационных сообщений.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js