Node.js. Паттерны проектирования и разработки

Здравствуйте, уважаемые читатели.

Нас заинтересовала книга "Node.js Design Patterns ^[1]", собравшая за год существования очень положительные отзывы, небанальная и содержательная.

Учитывая, что на российском рынке книги по Node.js можно буквально пересчитать по пальцам, предлагаем ознакомиться со статьей автора этой книги. В ней господин Кассиаро делает очень информативный экскурс в свою работу, а также объясняет тонкости самого феномена «паттерн» на материале Node.js.

Поучаствуйте, пожалуйста, в опросе.

Кроме классических паттернов проектирования ^[2], которые всем нам приходилось изучать и использовать на других платформах и в других языках, специалистам по Node.js то и дело приходится реализовывать в коде такие приемы и паттерны, которые обусловлены свойствами языка JavaScript и самой платформы

Преуведомление

Разумеется, паттерны проектирования, описанные бандой четырех, Gang of Four по-прежнему обязательны для создания правильной архитектуры. Но ни для кого не секрет, что в JavaScript нарушаются практически все правила, усвоенные нами в других языках. Паттерны проектирования – не исключение, будьте готовы, что в JavaScript придется переосмыслить старые правила и изобрести новые. Традиционные паттерны проектирования в JavaScript могут реализовываться с вариациями, причем обычные программерские уловки могут дорасти до статуса паттернов, поскольку они широко применимы, известны и эффективны. Кроме того, не удивляйтесь, что некоторые признанные антипаттерны ^[3] широко применяются в JavaScript/Node.js (например, часто упускается из виду правильная инкапсуляция ^[4], так как получить ее сложно, и она зачастую может приводить к «объектному разврату ^[5]», он же – антипаттерн «паблик Морозов».

Список

Далее следует краткий список распространенных паттернов проектирования, используемых в приложениях Node.js. Я не собираюсь вновь вам показывать, как реализуются на JavaScript «Наблюдатель ^[6]» или «Одиночка ^[7]», а хочу заострить внимание на характерных приемах, используемых в Node.js, которые можно обобщить под названием «паттерны проектирования».

Этот список я составил на материале из собственной практики, когда писал приложения Node.js и изучал код коллег, поэтому он не претендует ни на полноту, ни на окончательность. Любые дополнения приветствуются.
Причем я не удивлюсь, что вы уже встречали некоторые из этих паттернов или даже использовали их.

Требование директории (псевдо-плагины)

Этот паттерн – определенно один из самых популярных. Он заключается в том, чтобы потребовать все модули из директории, только и всего. При всей простоте это один из самых удобных и распространенных приемов. В Npm есть множество модулей, реализующих этот паттерн: хотя бы require-all ^[8], require-many ^[9], require-tree ^[10], require-namespace ^[11], require-dir ^[12], require-directory ^[13], require-fu ^[14].

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

Простой пример

var requireDir = require('require-all');
var routes = requireDir('./routes');

app.get('/', routes.home);
app.get('/register', routes.auth.register);
app.get('/login', routes.auth.login);
app.get('/logout', routes.auth.logout);

Более сложный пример (сниженная связность, расширяемость)

var requireFu = require('require-fu');

requireFu(__dirname + '/routes')(app);

Где каждая из /routes
– это функция, определяющая собственный url-маршрут:

module.exports = function(app) {
  app.get("/about", function(req, res) {
    // работаем
  });
}

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

Объект Приложение (самодельное внедрение зависимости)

Этот паттерн также очень распространен в других языках/на других платформах, но, в силу динамической природы JavaScript, этот паттерн оказывается очень эффективен (и популярен) в Node.js. В данном случае мы создаем один объект, который служит костяком всего приложения. Обычно этот объект инстанцируется на входе в приложение и служит клеем для различных прикладных сервисов. Я бы сказал, что он очень напоминает Фасад ^[15], но в Node.js он также широко применяется при реализации очень примитивного контейнера для внедрения зависимостей.

Типичный пример этого паттерна: в приложении есть объект App
(либо объект, одноименный самому приложению), и все сервисы после инициализации прикрепляются к этому большому объекту.

Пример

var app = new MyApp();

app.db = require('./db');
app.log = new require('./logger')();
app.express = require('express')();
app.i18n = require('./i18n').initialize();

app.models = require('./models')(app);

require('./routes')(app);

Затем App object можно передавать по мере необходимости, чтобы им пользовались другие модули, либо он может принимать форму аргумента функции или require


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

Но будьте внимательны: если пользоваться этим паттерном без обеспечения уровня абстракции над загруженными зависимостями, то у вас может получиться всезнающий объект, который сложно поддерживать и который, в принципе, по всем признакам напоминает антипаттерн God object ^[16].

К счастью, есть некоторые библиотеки, которые помогают справиться с этой проблемой – например, Broadway ^[17], архитектурный фреймворк, реализующий очень аккуратный вариант этого паттерна, обеспечивающий хорошую абстракцию и позволяющий лучше контролировать жизненный цикл сервиса.

Пример

var app = new broadway.App();
app.use(require("./plugins/helloworld"));
app.init(...);
app.hello("world");
// ./plugins/helloworld

exports.attach = function (options) {
  // "this" – это наш объект приложения!
  this.hello = function (world) {
    console.log("Hello "+ world + ".");
  };
};

Перехват функций (латание по-обезьяньи плюс AOP)

Перехват функций – еще один паттерн проектирования, типичный для динамических языков вроде JavaScript – как вы догадываетесь, он очень популярен и в Node.js. Он заключается в дополнении поведения функции (или метода) путем перехвата его (ее) выполнения. Обычно такой прием позволяет разработчику перехватить вызов до выполнения (prehook) или после (post hook). Тонкость заключается в том, что Node.js часто используется в комбинации с обезьяньим латанием ^[18], и эта техника оказывается очень мощной, но, в то же время, и опасной.

Пример

var hooks = require('hooks'), 
    Document = require('./path/to/some/document/constructor');

// Добавить методы перехвата: `hook`, `pre`и `post`
for (var k in hooks) {
  Document[k] = hooks[k];
}

Document.prototype.save = function () {
  // ...
};

// Определяем промежуточную функцию, которая будет вызываться после 'save'
Document.post('save', function createJob (next) {
  this.sendToBackgroundQueue();
  next();
});

Если вы когда-либо работали с Mongoose ^[19], то определенно видели этот паттерн в действии; если нет — в npm найдется масса подобных модулей ^[20] на любой вкус. Но это еще не все: в сообществе Node.js термин «аспектно-ориентированное программирование» (AOP) зачастую считается синонимом перехвата функций, загляните в npm ^[21] – и поймете, о чем я. Можно ли в самом деле называть это AOP? Мой ответ – НЕТ. AOP требует, чтобы мы применяли сквозную ответственность к срезу ^[22], а не прикрепляли вручную конкретное поведение к отдельной функции (или даже набору функций). С другой стороны, в гипотетическом AOP-решении на Node.js вполне могли бы применяться перехваты – тогда совет (advice) распространялся бы на множество функций, объединенных, к примеру, одним срезом, определяемым при помощи регулярного выражения. Все модули просматривались бы на соответствие этому выражению.

Конвейеры (промежуточный код)

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

function(/* input/output */, next) {
    next(/* err and/or output */)
}

Возможно, вы привыкли называть такие вещи промежуточным кодом (middleware) имея в виду Connect ^[23] или Express ^[24], но границы использования данного паттерна гораздо шире. Например, Hooks ^[25] – это популярная реализация перехватов (рассмотренных выше), объединяющая все pre/post функции в (промежуточный) конвейер, чтобы «обеспечить максимальную гибкость».

Как правило, этот паттерн реализуется тем или иным образом при помощи async.waterfall ^[26], или async.auto ^[27], или последовательности обещаний ^[28], причем может не просто управлять потоком выполнения, но и обеспечивать расширяемость той или иной части вашего приложения.

Пример: Async

async.waterfall([
    function(callback){
        callback(null, 'one', 'two');
    },
    function(arg1, arg2, callback){
        callback(null, 'three');
    }
]};

Черты конвейера есть и у другого популярного компонента Node.js. Как вы уже догадались, речь о так называемых потоках ^[29], а на что поток, если его нельзя конвейеризовать ^[30]? Тогда как промежуточный код и цепочки функций вообще – универсальное решение для управления потоком выполнения и расширяемостью, потоки лучше подходят для обработки передаваемых данных в форме байтов или объектов.

Пример: потоки

fs.createReadStream("data.gz")
    .pipe(zlib.createGunzip())
    .pipe(through(function write(data) {
        //... доводим данные до совершенства ...
        this.queue(data);
    })
    // Записываем в файл
    .pipe(fs.createWriteStream("out.txt"));

Выводы

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

Автор: Издательский дом «Питер»

Источник ^[31]