Парадигмы программирования

В книге "Чистая архитектура" Мартина Роберта говорится о том, что не нужно зависеть от фреймворков. Автор рассказывает и про себя, как он прошёл путь от программирования перфокарт, до самых современных парадигм.

Книга делится на несколько больших частей. Одна из них обсуждает парадигмы программирования, а именно структурное, объектно-ориентированное и функциональное. Главная его мысль в том, что каждая парадигма ограничивает программиста, в этом и есть их основное назначение.

Но дают ли парадигмы сверх этого какие-то новые возможности? Если считать ограничения возможностями, то да, дают. В конце концов появляются некие правила позволяющие использовать лучшие практики предстающие в виде конструкций языка.

Для структурного программирования это ветвления и циклы. Для объектно-ориентированного это объекты и классы. В функциональном программировании упор идёт на функции, которые можно передавать в качестве аргументов.

Линус Торвальдс о С++

Линус Торвальдс о С++

C++ — кошмарный язык. Его делает ещё более кошмарным тот факт, что множество недостаточно грамотных программистов используют его, до такой степени, что оказывается намного проще выкинуть его как мусор.

Откровенно говоря, даже если нет *никаких* причин для выбора Си, кроме того чтобы держать C++-программистов подальше — то одно это уже будет достаточно веским основанием для использования Си.

Я пришёл к выводу, что *действительно* предпочту выгнать любого, кто предпочтёт вести разработку проекта на C++, нежели на Си, чтобы этот человек не загубил проект, в который я вовлечён.

C++ приводит к очень, очень плохим проектным решениям. Неизбежно начинают применяться «замечательные» библиотечные возможности вроде STL, и Boost, и прочего мусора, которые могут «помочь» программированию, но порождают:

— невыносимую боль, когда они не работают (и всякий, кто утверждает, что STL и особенно Boost стабильны и портируемы, настолько погряз во лжи, что это даже не смешно)

— неэффективно абстрагированные программные модели, когда спустя два года обнаруживается, что какая-то абстракция была недостаточно эффективна, но теперь весь код зависит ото всех окружающих её замечательных объектных моделей, и её нельзя исправить, не переписав всё приложение.

Другими словами, единственный способ иметь хороший, эффективный, низкоуровневый и портируемый C++ сводится к тому, чтобы ограничиться всеми теми вещами, которые элементарно доступны в Си.

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

Когда эффективность является первостепенным требованием, «преимущества» C++ будут огромной ошибкой.

Мартин Роберт о фреймворках

Чистая архитектура. Мартин Роберт

Есть некоторые фреймворки, с которыми вы просто обязаны вступить в союз. Если, например, вы пишете на C++, вам почти наверняка придется вступить в союз с STL — избежать этого очень сложно. Если вы пишете на Java, вы будете вынуждены вступить в союз со стандартной библиотекой.

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

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

Бизнес-правила

А теперь вопрос, можно ли в действительно избежать зависимостей от фреймворков? И логично было бы получить ответ у того кто поднял этот вопрос в книге. В первую очередь Мартин Роберт говорит о бизнес-правилах, которые описываются вариантами использования.

Чистая архитектура. Мартин Роберт

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

Строго говоря, бизнес-правила — это правила или процедуры, делающие или экономящие деньги. Еще строже говоря, бизнес-правила — это правила, делающие или экономящие деньги независимо от наличия или отсутствия их реализации на компьютере. Они делают или экономят деньги, даже когда выполняются вручную.

Банк взимает N% за кредит — это бизнес-правило, которое приносит банку деньги. И неважно, имеется ли компьютерная программа, вычисляющая процент, или служащий вычисляет его на счетах.

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

Варианты использования

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

Да, кто-то может сказать, что можно создать обёртки и прочее, а внутри них подменять код ссылаясь на фреймворки.

Но...
1) Во-первых, это снижение эффективности кода на лишние вызовы.
2) Во-вторых, загромождение кода лишними деталями, что усложнит анализ.
3) В-третьих, всё это не поможет при смене языка программирования, а не только фреймворка как программной платформы.

Если уж Мартин Роберт топит за варианты использования, то получается нужно создавать программу на неком псевдоязыке и псевдофреймворке с использованием псевдокода, а так же модели использования выраженной в виде чертежа или изображения.

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

С другой стороны это всего лишь моё временное видение проблемы. Так ли это на самом деле? Может быть и нет.

Числовой мир

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

Взять для примера управление потоком исполнения. Да его можно обернуть ветвлениями и циклами. Можно создать функции и передавать управление потоком в них. Можно сделать эти функции членами класса, а глобальные обернуть в пространства имён.

Но в конечном итоге всё всегда будет сводится к числам, не важно данные ли это или управление потоком. Говорю я об этом потому, что если не воспринимать программирование за счёт парадигм, то как-то это всё равно нужно делать.

Само собой напрашивается решение в котором можно анализировать изменение чисел. Но этому будет мешать как чёрные ящики исполняемого кода, так и парадигмы программирования с огромным количеством налепленных на них абстракций.

Во втором случае даже, если код и виден, распутать его может быть крайне сложно. За абстракцией простого числа может скрываться сверхсложный программный "механизм", который очень далеко ушёл от простых машинных команд.

</head>
<body>
${cursor}
</body>
</html>

class ${name} 
{
public:
    ${name}(${args})
    {
        ${cursor}
    }
    virtual ~${name}()
    {
    }
};