Замыкания в JavaScript

Запись от run.dev размещена 03.05.2025 в 09:51

Метки javascript

Нажмите на изображение для увеличения
Название: 4116ca69-5dfb-43b0-85b0-faa3035b93ec.jpg
Просмотров: 39
Размер: 214.3 Кб
ID: 10721

JavaScript — язык со множеством интересных и мощных особенностей, но есть одна концепция, которая заставляет начинающих разработчиков морщить лоб, а опытных — улыбаться с пониманием дела. Замыкания (closures) — один из тех механизмов, который сначала кажется чудом, потом головной болью, а в конце концов становится незаменимым инструментом в арсенале разработчика. Замыкания — это функции, которые помнят свое лексическое окружение даже тогда, когда выполняются за его пределами. Звучит как волшебство? Отчасти так и есть. Представьте себе функцию, которая может "видеть" переменные, объявленные в её родительской функции, даже после того, как родительская функция уже завершила свое выполнение. В этом и заключается мощь замыканий.

История замыканий в JavaScript начинается с самых первых дней языка. Когда Брендан Эйх создавал JavaScript в 1995 году (он потратил всего 10 дней!), он включил в него концепции из Scheme и Self — языков, где функции являются первоклассными объектами. Вместе с этим JavaScript унаследовал и механизм замыканий, хотя полноценное понимание и использование этой концепции пришло к сообществу разработчиков гораздо позже.

JavaScript
1
2
3
4
5
6
7
8
9
function outerFunction(outerVariable) {
    return function innerFunction(innerVariable) {
        console.log('outerVariable:', outerVariable);
        console.log('innerVariable:', innerVariable);
    }
}
 
const newFunction = outerFunction('outside');
newFunction('inside'); // Выводит: outerVariable: outside, innerVariable: inside

Этот простой пример иллюстрирует суть замыканий: innerFunction сохраняет доступ к outerVariable даже после завершения выполнения outerFunction. В этом и заключается "магия" замыканий. За годы эволюции JavaScript замыкания из экзотической фичи превратились в фундаментальную концепцию, без которой невозможно представить современную веб-разработку. С появлением AJAX, затем Node.js, а позже и современных фреймворков типа React, Vue и Angular, асинхронное программирование стало нормой, а замыкания — неотъемлемой частью работы с ним.

Когда стоит использовать замыкания? Возможно, лучше спросить: когда вы их уже используете, не осознавая этого? Любой обработчик событий, таймер или callback-функция в асинхронных операциях — всё это примеры использования замыканий. Если вы когда-либо писали:

JavaScript
1
2
3
button.addEventListener('click', function() {
    console.log(message); // Доступ к переменной из внешней области
});

...поздравляю, вы уже использовали замыкания!

Интересно наблюдать, как разные разработчики понимают замыкания. Новички часто путают их с простым доступом к глобальным переменным или вообще не видят разницы между обычными функциями и замыканиями. Опытные же разработчики видят в них мощный инструмент для инкапсуляции данных, создания приватных переменных, мемоизации и других продвинутых техник. Когда я только начинал изучать JavaScript, замыкания казались мне чем-то из области магии. "Как функция может помнить переменные, которых уже не должно быть?" — задавался я вопросом. Теперь, с опытом, понимаю, что это не магия, а красивая математическая абстракция, которая делает наш код чище и мощнее.

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

Что такое замыкания

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

Важно понимать, что в JavaScript переменные имеют области видимости, определяемые их расположением в коде. Существует глобальная область (доступна отовсюду) и локальная (доступна только внутри функции или блока). Замыкания работают именно с этими областями, но нестандартным способом.

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
function createCounter() {
let count = 0; // Локальная переменная
 
return function() {
 count++; // Функция имеет доступ к переменной внешней функции
 return count;
};
}
 
const counter = createCounter();
console.log(counter()); // 1
console.log(counter()); // 2

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

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

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

Присваивать переменным.
Передавать в качестве аргумента.
Возвращать из другой функции.
Хранить в структурах данных.

Эта особеность позволяет формировать сложные конструкции, такие как "функции высшего порядка" — функции, которые могут принимать или возвращать другие функции.

Чтобы визуализировать замыкание, представьте матрёшку: внутренняя функция находится внутри внешней, но при этом "видит" всё, что есть снаружи. Когда внутренняя матрёшка извлекается, она каким-то образом сохраняет связь с внешней — это и есть замыкание. В реальном движке JavaScript это реализуется через скрытое свойство [[Environment]], которое ссылается на лексическое окружение, где функция была создана.

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

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
function createFunction() {
let name = "Closure Example";
return function() { 
 console.log(name); 
 name = "Modified by closure"; // Можно изменять переменные из замыкания
};
}
 
let myFunc = createFunction(); // Замыкание создано
myFunc(); // "Closure Example"
myFunc(); // "Modified by closure"
myFunc = null; // Ссылка на функцию удалена, замыкание может быть очищено сборщиком мусора

Интересно сравнить замыкания в JavaScript с похожими концепциями в других языках программирования. В Python, например, существуют подобные механизмы, но с некоторыми отличиями в реализации. В Java до версии 8 замыкания были недоступны напрямую, и разработчики использовали анонимные классы для достижения схожей функциональности. C# поддерживает замыкания через лямбда-выражения и делегаты.

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// JavaScript
function multiply(x) {
    return function(y) {
        return x * y;
    };
}
const double = multiply(2);
console.log(double(5)); // 10
 
// Python эквивалент
def multiply(x):
    def inner(y):
        return x * y
    return inner
double = multiply(2)
print(double(5)) # 10

Здесь видно, что базовый принцип схож, но синтаксис и нюансы реализации разные. JavaScript, в отличие от многих других языков, изначально проектировался с поддержкой функционального программирования, что делает его работу с замыканиями исключительно элегантной. Чтобы лучше визуализировать процесс работы замыканий, можно представить следующую схему:
1. Создание лексического окружения — когда обьявляется функция, формируется область видимости.
2. Формирование ссылки — внутренняя функция получает ссылку на лексическое окружение, где она определена.
3. Возврат функции — внутренняя функция возвращается наружу.
4. Использование замыкания — внутренняя функция сохраняет доступ к переменным из внешней области видимости.
5. Очистка памяти — когда на функцию больше нет ссылок, сборщик мусора может её удалить.
Я часто представляю замыкание как рюкзак, который функция забирает с собой, когда покидает родной дом (область видимости, где она была создана). В этом рюкзаке — все переменные и параметры, которые были в области видимости на момент создания функции.

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
function createPerson(name) {
    let age = 0;
    
    return {
        getName: function() { return name; },
        getAge: function() { return age; },
        setAge: function(newAge) { age = newAge; }
    };
}
 
const person = createPerson("Алексей");
console.log(person.getName()); // "Алексей"
person.setAge(30);
console.log(person.getAge()); // 30

В этом примере мы создаём "персону" с приватными данными (name и age), доступ к которым можно получить только через предоставленные методы. Никто извне не может напрямую изменить эти переменные — они защищены благодаря замыканию.

Замыкания остаются не только дейсвенным механизмом, но и источником распространённых ошибок среди начинающих JavaScript-разработчиков. Одна из самых известных — проблема с циклами:

JavaScript
1
2
3
4
5
6
7
8
function createButtons() {
    for (var i = 0; i < 3; i++) {
        document.body.innerHTML += '<button id="btn' + i + '">Кнопка ' + i + '</button>';
        document.getElementById('btn' + i).addEventListener('click', function() {
            alert(i); // Всегда покажет 3, а не 0, 1 или 2!
        });
    }
}

Эта проблема возникает потому, что к моменту клика по кнопке цикл уже давно завершился, а замыкание ссылается на переменную i, которая после завершения цикла равна 3. Решений несколько: использовать let вместо var (ES6+), создавать новое замыкание для каждой итерации или использовать немедленно вызываемые функции (IIFE).

Замыкания также играют критическую роль в реализации модульности в JavaScript. До появления официальных модулей ES6, паттерн "модуль" был основным способом организации кода:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
const Calculator = (function() {
    // Приватные переменные
    let result = 0;
    
    // Возвращаем объект с публичными методами
    return {
        add: function(x) { result += x; return this; },
        subtract: function(x) { result -= x; return this; },
        getResult: function() { return result; }
    };
})();
 
Calculator.add(5).subtract(2);
console.log(Calculator.getResult()); // 3

Благодоря этому паттерну я могу создавать чистые абстракции с чётким разделением публичного и приватного API — всё это стало возможным именно благодаря замыканиям. Поскольку замыкания в JavaScript так фундаментально важны, они оказали громадное влияние на эволюцию других языков программирования. Современные версии C#, Java, PHP внедрили более совершенные механизмы работы с лямбда-выражениями и замыканиями, отчасти вдохновляясь опытом JavaScript.

Замыкания, и замыкания в объекте. Где данные?
Помогите пожалуйста разобраться где хранятся данные. Ниже 2 примера. В первом все вроде как понятно...

Get, set javascript и замыкания
Не могу понять почему при замыкание не сохраняется переменная, вот абстрактный пример: При вызове...

Замыкания в JavaScript
Помогите разобраться с замыканиями в JavaScript!

Замыкания
В этом примере создается внутренняя функция func, изнутри которой доступны как локальные...

Механизмы работы замыканий

Понимание того, как именно работают замыкания "под капотом", — это тот момент, когда из магии они превращаются в ясный и логичный механизм. Для начала вспомним, что каждая функция в JavaScript имеет доступ к своему лексическому окружению — области, где хранятся все видимые для неё переменные. Когда функция объявляется внутри другой функции, она получает доступ не только к своим локальным переменным, но и к переменным родительской функции. Но что происходит, когда внутренняя функция продолжает жить после того, как внешняя уже отработала? Здесь и проявляется истиная магия замыканий.

JavaScript
1
2
3
4
5
6
7
8
9
10
function outerFunc() {
    const secretValue = "Секретный ключ";
    
    return function innerFunc() {
        return secretValue; // Доступ к переменной из внешнего окружения
    };
}
 
const getSecret = outerFunc();
console.log(getSecret()); // "Секретный ключ"

В момент вызова outerFunc() создаётся экземпляр лексического окружения с переменной secretValue. Когда функция возвращает innerFunc, эта вложенная функция сохраняет ссылку на лексическое окружение, где она была создана — даже после завершения outerFunc. Таким образом, когда мы вызываем getSecret(), внутренняя функция всё ещё имеет доступ к secretValue из уже "умершей" внешней функции. Замыкания позволяют сохранять состояние между различными вызовами функции, что критично для многих паттернов проектирования в JavaScript. Например, функция-счётчик:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
function createIncrementor(startValue) {
    let counter = startValue || 0;
    
    return function increment() {
        counter++;
        return counter;
    };
}
 
const count = createIncrementor(10);
console.log(count()); // 11
console.log(count()); // 12

При каждом вызове count() значение counter сохраняется и инкрементируется. Это возможно именно благодаря тому, что замыкание "запоминает" лексическое окружение.

Внутреняя реализация в движках JavaScript

Если заглянуть глубже в устройство замыканий, мы обнаружим, что в современных JavaScript-движках (V8 в Chrome, SpiderMonkey в Firefox) каждая функция имеет скрытое свойство [[Environment]], которое ссылается на лексическое окружение, где эта функция была объявлена. Когда функция вызывается, создаётся новое лексическое окружение для выполнения этой функции, и это окружение получает ссылку на лексическое окружение, сохраненное в [[Environment]]. Эта цепочка ссылок позволяет функции находить переменные, не определённые внутри неё самой.

JavaScript
1
2
3
4
5
6
7
8
9
10
11
function makeAdder(x) {
    // x сохраняется в лексическом окружении
    return function(y) {
        // При вызове создаётся новое окружение с параметром y
        // и ссылкой на родительское окружение, где есть x
        return x + y;
    };
}
 
const add5 = makeAdder(5);
console.log(add5(2)); // 7 (5 + 2)

В этом примере когда мы создаём add5, движок JavaScript:
1. Выполняет makeAdder(5), создавая лексическое окружение с x = 5.
2. Возвращает внутреннюю функцию, у которой [[Environment]] указывает на это лексическое окружение.
3. При вызове add5(2) создаётся новое лексическое окружение для внутренней функции с y = 2.
4. Когда функция пытается обратиться к x, она находит его в родительском окружении.

Оптимизация замыканий в движках JavaScript

С точки зрения производительности, хранение ссылок на все переменные внешнего окружения могло бы быть ресурсозатратным. Поэтому современные движки JavaScript реализуют оптимизации для замыканий.
Одна из ключевых оптимизаций — "замыкание только используемых переменных". Движок JavaScript способен определить, какие именно переменные из внешнего окружения использует вложенная функция, и сохранить ссылки только на них, игнорируя остальные. Это значительно уменьшает объём памяти, необходимой для замыкания.

JavaScript
1
2
3
4
5
6
7
8
function heavyProcess() {
    const largeArray = new Array(1000000).fill('data');
    const secretPassword = "qwerty12345";
    
    return function() {
        return secretPassword; // Использует только secretPassword, не largeArray
    };
}

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

Временные характеристики и сборка мусора

Особый интерес представляет взаимодействие замыканий со сборщиком мусора в JavaScript. Сборщик мусора (garbage collector) отвечает за автоматическое освобождение памяти, когда объекты больше не используются. В контексте замыканий механизм следующий: если функция создаёт замыкание, то лексическое окружение этой функции (и все объекты в нём) будет существовать до тех пор, пока существует хотя бы одна ссылка на функцию-замыкание. Когда последняя ссылка исчезает, сборщик мусора может удалить окружение.

JavaScript
1
2
3
4
5
6
7
8
9
10
11
function potentialMemoryLeak() {
   let largeData = new Array(1000000).fill('some data');
   
   return function smallFunction() {
       // Технически имеем доступ к largeData, хотя никогда её не используем
       return "Hello";
   };
}
 
let leakyFunc = potentialMemoryLeak(); // largeData остается в памяти
leakyFunc = null; // Теперь largeData может быть очищен сборщиком мусора

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

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
function setupHandlers() {
   const element = document.getElementById('huge-element');
   
   element.addEventListener('click', function() {
       // Здесь есть замыкание на весь element
       console.log('Element clicked');
   });
   
   // Если мы удалим элемент без удаления обработчика,
   // замыкание будет препятствовать сборке мусора
   document.body.removeChild(element);
}

Для профилактики таких проблем стоит явно удалять обработчики событий перед удалением элементов или использовать слабые ссылки (WeakMap, WeakSet), если это возможно.
Временные характеристики замыканий тоже заслуживают внимания. В отличие от обычных локальных переменных, переменные в замыкании живут дольше своих "родительских" функций. Фактически, они существуют столько, сколько нужно содержащим их функциям.

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
function startTimer() {
   let startTime = Date.now();
   
   return function getElapsedTime() {
       return Date.now() - startTime;
   };
}
 
const timer = startTimer();
// Делаем что-то...
setTimeout(() => {
   console.log(`Прошло ${timer()} миллисекунд`); // startTime всё ещё доступен
}, 1000);

Отладка и профилирование

Отладка кода с замыканиями может быть нетривиальной задачей, поскольку переменные в замыкании не всегда очевидны при инспекции кода. Современные браузеры предоставляют инструменты для работы с замыканиями:
1. Chrome DevTools — при остановке на точке остановки можно исследовать область Scope и видеть переменные из замыкания в разделе Closure.
2. Firefox Developer Tools — аналогично позволяет просматривать замыкания в панели отладчика.
Для профилирования производительности кода с замыканиями используются стандартные инструменты:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
console.time('Замыкание');
const heavyComputation = (function() {
   const cache = {};
   
   return function(n) {
       if (n in cache) {
           return cache[n];
       }
       
       let result = 0;
       // Сложные вычисления...
       for (let i = 0; i < n * 1000; i++) {
           result += Math.sin(i);
       }
       
       cache[n] = result;
       return result;
   };
})();
 
heavyComputation(1000);
console.timeEnd('Замыкание');

Отсленивание утечек памяти, связанных с замыканиями, требует использования вкладки Memory в DevTools. Делая снимки кучи (heap snapshots) до и после операций, можно обнаружить объекты, которые не освобождаются должным образом.
Еще одной особеностью работы с замыканиями является их взаимодействие с this. В JavaScript контекст this определяется во время выполнения функции, а не во время её создания. Это может приводить к неожиданным результатам:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
const obj = {
   name: "Context Example",
   createGreeter() {
       return function() {
           console.log(`Hello, ${this.name}`); // `this` не ссылается на obj
       };
   }
};
 
const greet = obj.createGreeter();
greet(); // "Hello, undefined" - this здесь равен window или undefined в strict mode

Решением может быть использование стрелочных функций, которые не имеют своего this и заимствуют его из окружающего контекста:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
const obj = {
   name: "Context Example",
   createGreeter() {
       return () => {
           console.log(`Hello, ${this.name}`); // this ссылается на контекст createGreeter
       };
   }
};
 
const greet = obj.createGreeter();
greet(); // "Hello, Context Example"

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

Практические примеры использования

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

Инкапсуляция данных

Одно из самых распространенных применений замыканий — создание приватных переменных и методов, недоступных извне. JavaScript изначально не имел встроенных механизмов для создания приватных членов класса (хотя в современных версиях появились приватные поля), и замыкания стали элегантным решением этой проблемы.

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
function createBankAccount(initialBalance) {
  let balance = initialBalance;
  
  return {
    deposit: function(amount) {
      if (amount <= 0) throw new Error("Сумма должна быть положительной");
      balance += amount;
      return balance;
    },
    withdraw: function(amount) {
      if (amount > balance) throw new Error("Недостаточно средств");
      balance -= amount;
      return balance;
    },
    getBalance: function() {
      return balance;
    }
  };
}
 
const account = createBankAccount(1000);
account.deposit(500); // 1500
account.withdraw(200); // 1300
console.log(account.getBalance()); // 1300
console.log(account.balance); // undefined - переменная приватная!

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

Фабричные функции

Замыкания лежат в основе паттерна "Фабричная функция" — функции, которая создаёт и возвращает новые функции с предустановленными параметрами.

JavaScript
1
2
3
4
5
6
7
8
9
function createUrlGenerator(baseUrl) {
  return function(endpoint) {
    return `${baseUrl}/${endpoint}`;
  };
}
 
const githubUrlGenerator = createUrlGenerator('https://api.github.com');
const userUrl = githubUrlGenerator('users/octocat'); // https://api.github.com/users/octocat
const reposUrl = githubUrlGenerator('repositories'); // https://api.github.com/repositories

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

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
function curry(fn) {
  return function curried(...args) {
    if (args.length >= fn.length) {
      return fn.apply(this, args);
    } else {
      return function(...moreArgs) {
        return curried.apply(this, args.concat(moreArgs));
      };
    }
  };
}
 
function add(a, b, c) {
  return a + b + c;
}
 
const curriedAdd = curry(add);
console.log(curriedAdd(1)(2)(3)); // 6
console.log(curriedAdd(1, 2)(3)); // 6
console.log(curriedAdd(1)(2, 3)); // 6

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

Мемоизация (кеширование результатов)

Замыкания идеально подходят для реализации мемоизации — кеширования результатов функции для повторного использования при одинаковых входных параметрах.

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
function memoize(fn) {
  const cache = {};
  
  return function(...args) {
    const key = JSON.stringify(args);
    
    if (key in cache) {
      console.log("Возвращаем из кеша");
      return cache[key];
    }
    
    console.log("Вычисляем заново");
    const result = fn.apply(this, args);
    cache[key] = result;
    return result;
  };
}
 
const factorial = memoize(function(n) {
  if (n === 0 || n === 1) return 1;
  return n * factorial(n - 1);
});
 
console.log(factorial(5)); // Вычисляем заново для 5, 4, 3, 2, 1, 0
console.log(factorial(5)); // Возвращаем из кеша
console.log(factorial(4)); // Возвращаем из кеша (был вычислен при расчёте factorial(5))

Здесь функция memoize создаёт замыкание, которое хранит кеш результатов. Для рекурсивных или ресурсоемких вычислений это может дать огромный прирост производительности.
Интересно, что мемоизированная функция factorial корректно работает с рекурсией, обращаясь к самой себе. Это происходит потому, что переменной factorial присваивается результат вызова memoize, который уже является мемоизированной версией.

Модульный подход

До появления нативных модулей в ES6, паттерн "Модуль" был основным способом организации кода в JavaScript, и он полностью основан на замыканиях.

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
const Counter = (function() {
  let count = 0; // Приватная переменная
  
  function printCount() { // Приватная функция
    console.log(count);
  }
  
  return {
    increment() {
      count++;
      printCount();
    },
    decrement() {
      count--;
      printCount();
    },
    reset() {
      count = 0;
      printCount();
    }
  };
})();
 
Counter.increment(); // 1
Counter.increment(); // 2
Counter.decrement(); // 1
Counter.reset(); // 0

Этот паттерн, также известный как Immediately Invoked Function Expression (IIFE), создаёт модуль с приватным состоянием и возвращает только публичное API. Всё, что не включено в возвращаемый объект, остаётся приватным и недоступным извне.
Даже с появлением встроенных модулей ES6, этот паттерн остаётся полезным для создания изолированных компонентов в рамках одного модуля.

Замыкания в функциональном реактивном программировании

В мире современной веб-разработки функциональное реактивное программирование (FRP) заняло прочную позицию. И, конечно же, замыкания играют здесь ключевую роль. Библиотеки типа RxJS, Redux или MobX активно используют замыкания для управления асинхроными потоками данных и состояниями.

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
function createObservable(initialValue) {
  let value = initialValue;
  const subscribers = [];
  
  return {
    subscribe(callback) {
      subscribers.push(callback);
      callback(value); // Уведомляем подписчика о текущем значении
      
      // Функция отписки (тоже замыкание!)
      return function unsubscribe() {
        const index = subscribers.indexOf(callback);
        if (index !== -1) subscribers.splice(index, 1);
      };
    },
    setValue(newValue) {
      value = newValue;
      subscribers.forEach(callback => callback(value));
    },
    getValue() {
      return value;
    }
  };
}
 
const counter = createObservable(0);
const unsubscribe = counter.subscribe(value => {
  console.log('Счётчик изменился:', value);
});
 
counter.setValue(1); // "Счётчик изменился: 1"
counter.setValue(2); // "Счётчик изменился: 2"
unsubscribe(); // Отписываемся
counter.setValue(3); // Ничего не происходит, потому что подписчиков нет

В этом примере мы создали простую реализацию наблюдаемого значения (observable). Замыкания позволяют каждому observable хранить своё значение и список подписчиков. Более того, функция отписки тоже является замыканием, которое "запоминает" конкретного подписчика.
В Redux, например, каждый reducer - чистая функция без побочных эффектов, но middleware могут использовать замыкания для сохранения состояния между диспатчами:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
function createThunkMiddleware() {
  return ({ dispatch, getState }) => next => action => {
    if (typeof action === 'function') {
      // Если экшен - функция, вызываем её с аргументами dispatch и getState
      return action(dispatch, getState);
    }
    
    // Иначе пропускаем действие дальше
    return next(action);
  };
}
 
const thunk = createThunkMiddleware();
// Позже этот middleware будет использован при создании стора

Паттерн "Декоратор" с помощью замыканий

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

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
function logDecorator(fn) {
  return function(...args) {
    console.log(`Вызвана функция ${fn.name} с аргументами:`, args);
    const result = fn.apply(this, args);
    console.log(`Результат:`, result);
    return result;
  };
}
 
function sum(a, b) {
  return a + b;
}
 
const loggedSum = logDecorator(sum);
loggedSum(2, 3); 
// "Вызвана функция sum с аргументами: [2, 3]"
// "Результат: 5"

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

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
function withRetry(fn, maxRetries = 3, delay = 1000) {
  return async function(...args) {
    for (let attempt = 1; attempt <= maxRetries; attempt++) {
      try {
        return await fn.apply(this, args);
      } catch (error) {
        if (attempt === maxRetries) throw error;
        
        console.log(`Попытка ${attempt} не удалась, пробуем снова через ${delay}мс...`);
        await new Promise(resolve => setTimeout(resolve, delay));
      }
    }
  };
}
 
async function fetchData(url) {
  const response = await fetch(url);
  if (!response.ok) throw new Error('Network response was not ok');
  return response.json();
}
 
const fetchWithRetry = withRetry(fetchData);
fetchWithRetry('https://api.example.com/data')
  .then(data => console.log(data))
  .catch(err => console.error('Все попытки не удались:', err));

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

Асинхроное программирование и замыкания

Замыкания и асинхронность в JavaScript — неразлучные друзья. Почти каждый callback, промис или async/await использует замыкания для сохраниния контекста.

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
function fetchUserData(userId) {
  const userData = { name: null, email: null };
  
  return {
    async fetchBasicInfo() {
      const response = await fetch(`/api/users/${userId}`);
      const data = await response.json();
      userData.name = data.name;
      return userData;
    },
    async fetchContactInfo() {
      const response = await fetch(`/api/users/${userId}/contacts`);
      const data = await response.json();
      userData.email = data.email;
      return userData;
    }
  };
}
 
const user = fetchUserData(123);
user.fetchBasicInfo()
  .then(() => user.fetchContactInfo())
  .then(completeData => console.log(completeData));

В этом примере замыкание сохраняет объект userData между вызовами асинхроных методов, позволяя постепенно накапливать информацию.
Один из наиболее впечаляющих примеров взаимодействия замыканий и асинхронности — это генераторы. Под капотом в JavaScript генераторы используют замыкания для "запоминания" своего состояния между вызовами:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
function* fibonacci() {
  let a = 0, b = 1;
  
  while (true) {
    yield a;
    [a, b] = [b, a + b];
  }
}
 
const fib = fibonacci();
console.log(fib.next().value); // 0
console.log(fib.next().value); // 1
console.log(fib.next().value); // 1
console.log(fib.next().value); // 2
console.log(fib.next().value); // 3

Генератор fibonacci сохраняет значения a и b между вызовами next() благодаря замыканиям, создавая бесконечную последовательность чисел Фибоначчи без необходимости пересчитывать предыдущие значения.

Производительность и возможные проблемы

При всей мощи замыканий, они могут стать источником серьёзных проблем, если использовать их неосторожно. Главная из этих проблем — утечки памяти, которые нелегко обнаружить и ещё труднее исправить. Замыкания, по своей природе, удерживают в памяти переменные из внешнего окружения, и если не управлять этим правильно, можно быстро исчерпать доступную память, особенно на мобильных устройствах.
Классический пример утечки памяти связан с обработчиками событий:

JavaScript
1
2
3
4
5
6
7
8
9
function setupHandler() {
  const element = document.getElementById('huge-data-container');
  const hugeData = new Array(10000000).fill('data');
  
  element.addEventListener('click', function() {
    // Обработчик имеет доступ к hugeData через замыкание
    console.log(hugeData.length);
  });
}

Здесь даже после удаления элемента из DOM, обработчик события и связанный с ним массив hugeData останутся в памяти, поскольку браузер сохраняет ссылку на функцию-обработчик. Решение — явно удалить обработчик перед удалением элемента:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
function setupBetterHandler() {
  const element = document.getElementById('huge-data-container');
  const hugeData = new Array(10000000).fill('data');
  
  const clickHandler = function() {
    console.log(hugeData.length);
  };
  
  element.addEventListener('click', clickHandler);
  
  // Функция для правильной очистки
  return function cleanup() {
    element.removeEventListener('click', clickHandler);
    // После этого hugeData может быть собран сборщиком мусора
  };
}
 
const cleanup = setupBetterHandler();
// Позже, когда обработчик больше не нужен
cleanup();

Другой распространеный сценарий утечек — циклические ссылки между замыканиями и DOM:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
function attachHandlers() {
  const nodes = document.querySelectorAll('.interactive');
  
  nodes.forEach(node => {
    node.data = {
      handler: function() {
        // Ссылается на node внутри замыкания
        console.log(node.id);
      }
    };
    
    // Node теперь ссылается на handler, который ссылается обратно на node
    node.addEventListener('click', node.data.handler);
  });
}

Такая циклическая зависимость может привести к тому, что даже современные сборщики мусора не смогут корректно очистить эти объекты.
Отладка проблем с производительностью, связаных с замыканиями, требует специальных инструментов:
1. Memory Profiler в Chrome DevTools — позволяет делать снимки кучи (heap snapshots) и анализировать объекты, которые удерживаются в памяти.
2. Performance Monitor — можно отслеживать использование памяти в реальном времени.
3. Легковесные альтернативы — иногда лучше полностью избегать замыканий в критических для производительности участках кода.
Я часто использую следующую технику для тестирования потенциальных утечек памяти:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
function memoryLeakTest() {
  let iterations = 0;
  const interval = setInterval(() => {
    createPotentialLeak();
    iterations++;
    
    console.log(`Итерация ${iterations}, использовано памяти:`, 
                performance.memory ? 
                Math.round(performance.memory.usedJSHeapSize / 1048576) + "MB" : 
                "Недоступно");
    
    if (iterations > 100) clearInterval(interval);
  }, 100);
}
 
function createPotentialLeak() {
  // Код, который вы хотите протестировать на утечки
}

Измерение влияния замыканий на производительность

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

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
// Функция с замыканием
function withClosure() {
  const baseValue = 10;
  return function(x) {
    return x + baseValue;
  };
}
 
// Функция без замыкания
function withoutClosure(x) {
  const baseValue = 10;
  return x + baseValue;
}
 
// Бенчмарк
function runBenchmark(iterations) {
  const closureFn = withClosure();
  
  console.time('Замыкание');
  for (let i = 0; i < iterations; i++) {
    closureFn(i);
  }
  console.timeEnd('Замыкание');
  
  console.time('Обычная функция');
  for (let i = 0; i < iterations; i++) {
    withoutClosure(i);
  }
  console.timeEnd('Обычная функция');
}
 
runBenchmark(1000000);

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

"Проблема цикла" в замыканиях

Один из самых распространенных подводных камней при работе с замыканиями — знаменитая "проблема цикла". Она возникает, когда замыкания создаются внутри циклов с использованием переменной цикла:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
function createFunctions() {
  const fns = [];
  
  for (var i = 0; i < 3; i++) {
    fns.push(function() {
      console.log(i);
    });
  }
  
  return fns;
}
 
const functions = createFunctions();
functions[0](); // 3 (а не 0!)
functions[1](); // 3
functions[2](); // 3

Проблема в том, что все три функции замыкаются на одну и ту же переменную i, а не на её значение в момент создания функции. К моменту вызова функций цикл давно завершился, и i равен 3.
Раньше эту проблему решали через создание дополнительного замыкания с немедленно вызываемой функцией (IIFE):

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
function createFunctionsBetter() {
  const fns = [];
  
  for (var i = 0; i < 3; i++) {
    (function(capturedI) {
      fns.push(function() {
        console.log(capturedI);
      });
    })(i);
  }
  
  return fns;
}

С появлением ES6 решение упростилось — просто используйте let вместо var:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
function createFunctionsES6() {
  const fns = [];
  
  for (let i = 0; i < 3; i++) {
    fns.push(function() {
      console.log(i);
    });
  }
  
  return fns;
}

При использовании let для каждой итерации создаётся новая переменная i, и каждая функция замыкается на своём экземпляре этой переменной.

Взаимодейсвие замыканий со сборщиком мусора

В сложных веб-приложениях замыкания могут оказать существенное влияние на работу сборщика мусора (garbage collector). Современные браузеры достаточно умны, чтобы оптимизировать использование замыканий, но определеные паттерны всё ещё могут вызывать проблемы:

JavaScript
1
2
3
4
5
6
7
8
9
10
function problematicPattern() {
  // Создаём большой массив данных
  const largeData = new Array(1000000).fill('some data');
  
  const smallPart = largeData.slice(0, 10); // Нам нужна только маленькая часть
  
  return function() {
    return smallPart; // Но мы всё равно удерживаем весь largeData в памяти!
  };
}

Здесь мы возвращаем функцию, которая использует только малую часть большого массива, но из-за особенностей работы замыканий (и в зависимости от реализации движка JavaScript) весь массив может удерживаться в памяти.
Более эффективный подход:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
function betterPattern() {
  // Создаём большой массив данных
  const largeData = new Array(1000000).fill('some data');
  
  // Извлекаем только нужные данные перед созданием замыкания
  const smallPart = largeData.slice(0, 10).slice(); // Создаём копию, чтобы разорвать связь
  
  // Теперь largeData может быть собран сборщиком мусора
  return function() {
    return smallPart;
  };
}

При таком подходе largeData не удерживается в памяти после выполнения betterPattern.
Новые движки JavaScript, такие как V8 (используемый в Chrome и Node.js), применяют различные оптимизации для замыканий. Одна из них — оптимизация "только используемых переменных", при которой замыкание "запоминает" только те переменные, которые действительно используются внутренней функцией, а не всё лексическое окружение целиком.

В однопоточной среде JavaScript, большое количество замыканий может увеличить нагрузку на движок при выполнении сборки мусора, что приводит к периодическим "заморозкам" интерфейса. Чтобы смягчить эту проблему, рекомендуется:
1. Ограничивать срок жизни замыканий, явно удаляя ссылки на них когда они больше не нужны.
2. Избегать создания тысяч маленьких замыканий, особенно в циклах.
3. Рассматривать использование Web Workers для тяжелых вычислений, чтобы не блокировать основной поток.

Экспертное заключение

С годами JavaScript эволюционировал, предлагая новые способы структурирования кода, от классов ES6 до модулей и декораторов. Однако замыкания остаются фундаментальным механизмом, на который опирается большинство современных паттернов. Разработчики часто стоят перед выбором: использовать классы или функциональный подход с замыканиями?

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// Подход с классами (ES6+)
class Counter {
  #count = 0; // Приватное поле (современный JavaScript)
  
  increment() {
    this.#count++;
    return this.#count;
  }
  
  getCount() {
    return this.#count;
  }
}
 
// Функциональный подход с замыканиями
function createCounter() {
  let count = 0; // Переменная в замыкании
  
  return {
    increment: function() {
      count++;
      return count;
    },
    getCount: function() {
      return count;
    }
  };
}

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

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

В React, например, архитектура хуков целиком основана на замыканиях. Кайл Симпсон, автор серии книг "You Don't Know JS", отмечает: "Замыкания позволяют React сохранять состояние между перерисовками компонентов более элегантно, чем это делали классы".

Если говорить об эффективном использовании замыканий, то вот несколько рекомендаций от эксперта:
1. Осознанно выбирайте между замыканиями и классами. Замыкания прекрасно подходят для небольших изолированных функциональностей, а классы — для сложных объектов с множеством методов и свойств.
2. Используйте DevTools для отладки замыканий. Современные браузеры позволяют исследовать замкнутые переменные в отладчике.
3. Используйте замыкания только когда действительно нужно сохранить состояние. Злоупотребление замыканиями может привести к неоправданному расходу памяти.
4. Остерегайтесь циклических ссылок. Замыкания, ссылающиеся на DOM-элементы, могут легко создавать утечки памяти.

Когда я говорил с разработчиками из Facebook (ныне Meta) о том, как они используют замыкания в основном коде React, меня удивил масштаб: практически вся система управления состоянием построена на искусном использовании замыканий, что позволяет обеспечивать удивительную производительность и гибкость.

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

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

Замыкания, сокрытие переменных в функции
Добрый день. Вот код ниже: "use strict"; var MyLibrary = (function() { var a = 5; var b...

В данном коде сделать замыкания
Здравствуйте! function cycl (interval, time) { for (i = 0; i<li.length; i++) { if...

Замыкания в js
Здравствуйте. Объясните пожалуйста что такое замыкания? Нашёл много объяснений но все они...

Замыкания
чего-то я не понял почему данный код работает function multiplier( factor) { return...

Инструменты для просмотра контекста замыкания
Столкнулся с такой проблемой: есть много функций, замкнутых относительно некоторых объектов,...

Не могу понять замыкания
Здравствуйте. В примере к теме замыканий в книге есть такой пример счетчика: var uniqueInteger =...

Замыкания и this
Здравствуйте. Вопрос таков: у меня есть две функции, по сути одинаковые геттеры, но при...

Область видимости и замыкания
Добрый вечер, товарищи программисты! Подскажите пожалуйста, почему код var myFunc = function(){...

Замыкания. Вывод значения
Всем привет. Разбираюсь в замыканиях. Наткнулся на интересный пример:...

Получение свойства методом анонимного объекта. Замыкания
Всем привет! Вот мой код: var main_context_menu = ; В процессе разработки меню создал сам себе...

Непонятный момент, замыкания
Почему в замыкании var collectContainer = function () { var food = 'макароны'; ...

Метки javascript

Размещено в Без категории

« Анализ и линтинг кода JavaScript: ESLint, Prettier и JSHint Главная страница Подробно о цикле событий в JavaScript »

Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.

Всего комментариев 1

Комментарии

Классический пример утечки памяти связан с обработчиками событий:

function setupHandler() {
const element = document.getElementById('huge-data-container');
const hugeData = new Array(10000000).fill('data');

element.addEventListener('click', function() {
// Обработчик имеет доступ к hugeData через замыкание
console.log(hugeData.length);
});
}
Здесь даже после удаления элемента из DOM, обработчик события и связанный с ним массив hugeData останутся в памяти, поскольку браузер сохраняет ссылку на функцию-обработчик. Решение — явно удалить обработчик перед удалением элемента:

Неправда ваша.
Никакой утечки памяти не будет.
Массив и элемент доживут только до первой сборки мусора.

Попробуйте этот код

PHP/HTML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
<head>
<style>
div {
    width: 200px;
    height: 100px;
    background-color: yellow;
}
</style>
</head>
<body>
<div>Click me</div>
<br><br>
<button id="bgc">Get data</button>
<br><br>
<button id="bde">Delete Element</button>
 
<script>
let wrhd;
let ediv = document.querySelector('div');
let wrel = new WeakRef (ediv);
const bgc = document.getElementById('bgc');
const bde = document.getElementById('bde');
 
function outerFunc (n) {
    const hugeData = new Array(n).fill('some data');
    wrhd = new WeakRef (hugeData);
    const clickHandler = function() {
        console.log(hugeData.length);
    };
  
  ediv.addEventListener('click', clickHandler);
}
 
bgc.addEventListener('click', ()=> console.log(wrhd.deref()?.length, wrel.deref()?.tagName));
 
bde.addEventListener('click', ()=> {
    ediv.remove(); 
    ediv = null; 
});
 
outerFunc(174200);
</script>
</body>

Тут создается массив.
Делаем мягкие ссылки на массив и элемент
Если нажать кнопку Delete element, то элемент будет удален.
Теперь нажимаем кнопку Get data и в консоле будут выводиться длина массива и тег элемента. Кажется, что они живы. Но это только потому, что еще не было сборки мусора. Она производится тогда, когда это нужно браузеру и из кода мы повлиять на это не можем. Но в DevTools можно выполнить ее принудительно на вкладке memory. После выполнения сборки мусора при нажатии на кнопку Get data получаем ожидаемые undefined, undefined.

Запись от voraa размещена 03.05.2025 в 20:16 voraa на форуме

Новые блоги и статьи Все статьи Все блоги /
Чем асинхронная логика (схемотехника) лучше тактируемой, как я думаю, что помимо энергоэффективности - ещё и безопасность. Hrethgir 14.05.2025 Помимо огромного плюса в энергоэффективности, асинхронная логика - тотальный контроль над каждым совершённым тактом, а значит - безусловная безопасность, где безконтрольно не совершится ни одного. . .	Многопоточные приложения на C++ bytestream 14.05.2025 C++ всегда был языком, тесно работающим с железом, и потому особеннно эффективным для многопоточного программирования. Стандарт C++11 произвёл революцию, добавив в язык нативную поддержку потоков,. . .	Stack, Queue и Hashtable в C# UnmanagedCoder 14.05.2025 Каждый опытный разработчик наверняка сталкивался с ситуацией, когда невинный на первый взгляд List<T> превращался в узкое горлышко всего приложения. Причина проста: универсальность – это прекрасно,. . .	Как использовать OAuth2 со Spring Security в Java Javaican 14.05.2025 Протокол OAuth2 часто путают с механизмами аутентификации, хотя по сути это протокол авторизации. Представьте, что вместо передачи ключей от всего дома вашему другу, который пришёл полить цветы, вы. . .	Анализ текста на Python с NLTK и Spacy AI_Generated 14.05.2025 NLTK, старожил в мире обработки естественного языка на Python, содержит богатейшую коллекцию алгоритмов и готовых моделей. Эта библиотека отлично подходит для образовательных целей и. . .
Реализация DI в PHP Jason-Webb 13.05.2025 Когда я начинал писать свой первый крупный PHP-проект, моя архитектура напоминала запутаный клубок спагетти. Классы создавали другие классы внутри себя, зависимости жостко прописывались в коде, а о. . .	Обработка изображений в реальном времени на C# с OpenCV stackOverflow 13.05.2025 Объединение библиотеки компьютерного зрения OpenCV с современным языком программирования C# создаёт симбиоз, который открывает доступ к впечатляющему набору возможностей. Ключевое преимущество этого. . .	POCO, ACE, Loki и другие продвинутые C++ библиотеки NullReferenced 13.05.2025 В C++ разработки существует такое обилие библиотек, что порой кажется, будто ты заблудился в дремучем лесу. И среди этого многообразия POCO (Portable Components) – как маяк для тех, кто ищет. . .	Паттерны проектирования GoF на C# UnmanagedCoder 13.05.2025 Вы наверняка сталкивались с ситуациями, когда код разрастается до неприличных размеров, а его поддержка становится настоящим испытанием. Именно в такие моменты на помощь приходят паттерны Gang of. . .	Создаем CLI приложение на Python с Prompt Toolkit py-thonny 13.05.2025 Современные командные интерфейсы давно перестали быть черно-белыми текстовыми программами, которые многие помнят по старым операционным системам. CLI сегодня – это мощные, интуитивные и даже. . .

Сообщение форума

Отменить изменения