Технологии ООП в C++ и C#: Полное Руководство по Экзаменационным Вопросам

В мире, где программное обеспечение проникает во все сферы нашей жизни, от повседневных мобильных приложений до критически важных промышленных систем, понимание фундаментальных принципов его создания становится не просто желательным, а жизненно необходимым. Для студента технической или ИТ-специальности, погружающегося в мир C++ и C#, объектно-ориентированное программирование (ООП) является краеугольным камнем, формирующим каркас мышления современного разработчика. Это не просто набор правил, а целая философия, позволяющая создавать сложные, масштабируемые и легко поддерживаемые системы.

Данное руководство призвано стать всеобъемлющим и технически точным справочником, деконструирующим тридцать экзаменационных вопросов по курсу «Технологии ООП» в единое, логически структурированное повествование. Мы не просто ответим на вопросы, но и погрузимся в глубины механизмов, сравнивая синтаксические конструкции и архитектурные решения двух мощнейших языков — C++ и C#. Особое внимание будет уделено не только высокоуровневым концепциям, но и низкоуровневым деталям, таким как таблицы виртуальных методов, поколенческая сборка мусора и тонкости синхронизации потоков в Windows API, что позволит сформировать целостное и глубокое понимание предмета, отвечая на скрытый вопрос: «Какие практические последствия имеют эти различия для архитектуры и производительности ваших будущих приложений?»

Введение в Объектно-Ориентированное Программирование

Что такое парадигма программирования?

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

Исторический контекст и эволюция парадигм

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

Однако для практического применения, особенно с появлением первых компьютеров, большее распространение получила процедурная парадигма, корни которой уходят в 1940-е годы и ассоциируются с архитектурой Фон Неймана. Революционным моментом стало создание языка Fortran (FORmula TRANslator) в 1957 году под руководством Джона Бэкуса в IBM. Fortran стал первым практически применимым высокоуровневым языком, который эффективно реализовал концепцию подпрограмм (процедур). Это позволило разбивать сложные задачи на более мелкие, управляемые блоки кода, значительно упрощая разработку и отладку. Процедурное программирование доминировало на протяжении десятилетий, но по мере роста сложности программного обеспечения стали очевидны его ограничения, особенно в управлении данными и повторном использовании кода.

В начале 1960-х годов, норвежские ученые Оле-Йохан Даль и Кристен Нюгор, работая над моделированием сложных систем (таких как симуляция движения кораблей), столкнулись с необходимостью более интуитивного и модульного подхода. Это привело к рождению объектно-ориентированного программирования (ООП) и созданию языка Simula 67 (1967 год), который стал пионером в поддержке концепций классов и объектов. Simula 67 представил идею о том, что программные сущности могут имитировать реальный мир, обладая как состоянием (данными), так и поведением (методами). Это был прорыв, который заложил основы для всей последующей эволюции ООП.

Фундаментальные концепции и преимущества ООП

Итак, что же такое ООП? Это методология программирования, которая организует программное обеспечение вокруг понятия «объекта», а не «действия» или «логики». Объект объединяет в себе:

• Данные (состояние): Характеристики, описывающие объект (например, цвет, размер, имя).
• Методы (поведение): Функции, которые оперируют данными объекта или выполняют действия, связанные с объектом (например, изменить цвет, рассчитать площадь).

Основное преимущество ООП заключается в значительном улучшении ряда критически важных аспектов разработки программного обеспечения:

1. Модульность: Программы строятся из независимых, самодостаточных блоков (объектов), которые взаимодействуют друг с другом. Это делает систему более понятной и управляемой.
2. Повторное использование кода: Благодаря механизмам наследования и классов, уже написанный и отлаженный код может быть легко переиспользован для создания новых сущностей, что сокращает время разработки и повышает надежность.
3. Масштабируемость: Модульная структура позволяет легко добавлять новую функциональность или изменять существующую, не затрагивая при этом другие части системы.
4. Гибкость: ООП позволяет создавать более адаптивные системы, способные легко реагировать на изменения требований.
5. Упрощение сопровождения: В контексте крупных корпоративных систем, основное преимущество ООП проявляется в уменьшении сложности сопровождения и повышении гибкости при модификации кода. Изменения в реализации одного класса, как правило, не требуют изменений в других, благодаря принципам инкапсуляции и абстракции, что значительно снижает риски и стоимость поддержки.

В основе ООП лежат два ключевых понятия:

• Класс: Это шаблон, «чертеж» или прототип для создания объектов. Он описывает общую структуру (поля, свойства) и поведение (методы), которые будут присущи всем экземплярам этого класса. Например, класс Автомобиль описывает, что у всех автомобилей есть цвет, модель, скорость (данные) и они могут ехать, тормозить, заправляться (методы).
• Объект: Это конкретный экземпляр класса. Если класс Автомобиль — это чертеж, то Мой_красный_седан или Грузовик_соседа — это конкретные объекты (экземпляры) этого класса, каждый со своим уникальным состоянием (например, у одного цвет = красный, у другого цвет = синий).

Основные Принципы ООП: Инкапсуляция, Наследование, Полиморфизм и Абстракция

На протяжении всего XX века, когда бурно развивались парадигмы программирования, фундаментальные концепции Объектно-Ориентированного Программирования (ООП) стали своего рода «золотым стандартом» для создания сложных программных систем. Эти концепции, часто называемые «тремя столпами», включают Инкапсуляцию, Наследование и Полиморфизм. В C#, к ним часто добавляют и Абстракцию как четвертый, неразрывно связанный принцип.

Инкапсуляция: Сокрытие данных и контроль доступа

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

Модификаторы доступа определяют видимость членов класса (полей, методов, свойств) для других частей программы. В C++ и C# используются общие принципы:

• private: Члены, объявленные как private, доступны только внутри того класса, где они определены. Это обеспечивает максимальное сокрытие информации.
• protected: Члены, объявленные как protected, доступны внутри своего класса и в классах-потомках (наследниках). Это позволяет производным классам взаимодействовать с внутренней логикой базового класса, сохраняя при этом некоторую степень защиты от внешнего мира.
• public: Члены, объявленные как public, доступны из любого места в программе. Они представляют собой внешний интерфейс класса, через который пользователи объекта взаимодействуют с ним.

Пример синтаксиса C++ (Инкапсуляция):

class MyClass {
private:
    int privateData; // Скрытые данные, доступны только внутри MyClass
protected:
    int protectedData; // Доступны внутри MyClass и в классах-наследниках
public:
    // Публичный метод для контролируемого доступа к privateData
    void set_data(int val) {
        if (val >= 0) { // Пример логики валидации
            privateData = val;
        }
    }
    int get_data() const {
        return privateData;
    }
};

Пример синтаксиса C# (Инкапсуляция):

public class MyClass
{
    private int _privateData; // Скрытые данные, доступны только внутри MyClass
    protected int ProtectedData { get; set; } // Доступны внутри MyClass и в классах-наследниках

    // Публичное свойство (Property) для контролируемого доступа к _privateData
    public int PublicData
    {
        get { return _privateData; }
        set
        {
            if (value >= 0) // Пример логики валидации
            {
                _privateData = value;
            }
        }
    }
}

В C# часто используются свойства (Properties), которые представляют собой синтаксический сахар над парами get и set методов, обеспечивая инкапсуляцию, но с более удобным синтаксисом доступа, имитирующим прямое обращение к полю.

Наследование: Расширение функциональности и иерархии классов

Наследование — это мощный механизм ООП, позволяющий создавать новые классы (называемые подклассами, производными или классами-потомками) на основе уже существующих классов (базовых, родительских или суперклассов). Суть наследования заключается в том, что производный класс автоматически заимствует (наследует) структуру (поля, свойства) и поведение (методы) базового класса, а затем может расширять и/или специализировать их, добавляя новые члены или изменяя поведение унаследованных. Это способствует повторному использованию кода и построению естественных иерархий типов, отражающих реальный мир (например, Кот наследует от Животное).

Сравнение моделей наследования в C++ и C#:

• C++: Множественное наследование:
  C++ является одним из немногих объектно-ориентированных языков, который поддерживает множественное наследование классов. Это означает, что один класс может наследовать от нескольких базовых классов одновременно. Синтаксически это выглядит так: class Derived : public Base1, public Base2 { /* ... */ };.
  Хотя множественное наследование предоставляет большую гибкость, оно также может приводить к серьезным проблемам, таким как конфликты имен (когда у разных базовых классов есть методы с одинаковыми сигнатурами) и, что более важно, «проблема ромбовидного наследования» (Diamond Problem).
• C#: Одиночное наследование классов и множественная реализация интерфейсов:
  C# (как и Java) сознательно отказался от множественного наследования классов именно из-за вышеупомянутых проблем. В C# класс может наследовать только от одного базового класса (class Derived : Base { /* ... */ }).
  Однако C# предлагает элегантное решение для достижения гибкости, схожей с множественным наследованием, без его недостатков — это множественная реализация интерфейсов. Класс может реализовать множество интерфейсов (class MyClass : MyBaseClass, IInterface1, IInterface2 { /* ... */ }). Интерфейс определяет контракт (набор методов, свойств, событий), но не предоставляет их реализацию. Класс, реализующий интерфейс, обязуется предоставить реализации всех его членов.

Проблема ромбовидного наследования (Diamond Problem):

Эта проблема является классическим примером сложности, которую вносит множественное наследование. Представьте себе следующую иерархию:

• Класс A (Базовый класс)
• Классы B и C наследуют от A
• Класс D наследует от B и C

Если класс A содержит некий метод foo(), а классы B и C не переопределяют его, то при создании объекта класса D и вызове d.foo(), возникает неопределенность: какой из методов foo() должен быть вызван — тот, что пришел от B (через A), или тот, что пришел от C (через A)? Компилятору непонятно, какую «копию» метода A::foo() использовать. Эта ситуация формирует на диаграмме наследования фигуру, похожую на ромб.

C# (и Java) избегают этой проблемы, поскольку интерфейсы не содержат реализации методов, а лишь их сигнатуры. Если класс реализует два интерфейса, которые оба объявляют метод с одинаковой сигнатурой, класс-реализатор должен предоставить одну единственную реализацию этого метода, тем самым устраняя двусмысленность.

Абстракция: Фокусировка на существенном и скрытие деталей

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

В C# для создания абстрактных представлений используются следующие механизмы:

• Абстрактные классы (abstract class): Это классы, которые не могут быть инстанцированы напрямую (то есть нельзя создать их объекты). Они предназначены для того, чтобы служить базовыми классами для других классов. Абстрактные классы могут содержать как реализованные методы, так и абстрактные методы (объявленные с ключевым словом abstract). Абстрактный метод не имеет реализации в базовом классе и обязательно должен быть переопределен в любом неабстрактном классе-наследнике.
  Пример синтаксиса C# (Абстрактный класс):

  public abstract class Shape // Абстрактный класс
  {
      public string Name { get; set; }
      public abstract double CalculateArea(); // Абстрактный метод без реализации
      public void DisplayName() // Обычный метод с реализацией
      {
          Console.WriteLine($"Shape: {Name}");
      }
  }
  
  public class Circle : Shape
  {
      public double Radius { get; set; }
      public override double CalculateArea() // Обязательная реализация абстрактного метода
      {
          return Math.PI * Radius * Radius;
      }
  }
  

• Интерфейсы (interface): Интерфейсы определяют контракт, который должен быть реализован классами. Они могут содержать только объявления методов, свойств, событий или индексаторов, но не их реализации (до C# 8.0, где появилась возможность default-реализаций). Класс может реализовывать несколько интерфейсов, что позволяет ему «обещать» реализацию различных наборов поведений.
  Пример синтаксиса C# (Интерфейс):

  public interface IResizable
  {
      void Resize(int percentage);
  }
  
  public class Window : IResizable
  {
      public void Resize(int percentage)
      {
          // Логика изменения размера окна
          Console.WriteLine($"Window resized by {percentage}%");
      }
  }
  

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

Полиморфизм: Статическое и Динамическое Связывание

В основе гибкости и расширяемости объектно-ориентированных систем лежит концепция полиморфизма, что в переводе с греческого означает «множество форм». Это свойство позволяет одному и тому же имени (например, имени метода) использоваться для выполнения схожих, но технически разных задач, или, что более мощно, позволяет объектам разных классов реагировать на один и тот же вызов по-разному в зависимости от их фактического типа. Полиморфизм является ключом к созданию кода, который может работать с объектами общего типа, но при этом автоматически адаптироваться к специфике конкретных подтипов.

Определение и виды полиморфизма

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

1. Статический полиморфизм (времени компиляции, раннее связывание): Этот вид полиморфизма определяется и разрешается компилятором на этапе компиляции программы. Компилятор точно знает, какой метод будет вызван, основываясь на сигнатуре (имени и параметрах) метода.
2. Динамический полиморфизм (времени выполнения, позднее связывание): Этот вид полиморфизма определяется только на этапе выполнения программы. Выбор конкретной реализации метода происходит в зависимости от фактического типа объекта, на который указывает ссылка или указатель, а не от типа самой ссылки/указателя.

Статический полиморфизм: Перегрузка методов и оп��раторов

Статический полиморфизм проявляется через два основных механизма:

• Перегрузка методов (Function/Method Overloading): Позволяет определить несколько методов с одним и тем же именем в одном классе, но с разными сигнатурами (разное количество параметров, разные типы параметров или их порядок). Компилятор выбирает нужную версию метода, исходя из типов и количества аргументов, переданных при вызове.

Пример C++ (Перегрузка методов):

class Calculator {
public:
    int add(int a, int b) { return a + b; }
    double add(double a, double b) { return a + b; } // Перегрузка
    int add(int a, int b, int c) { return a + b + c; } // Еще одна перегрузка
};
// Использование:
// Calculator calc;
// calc.add(1, 2);      // Вызовет int add(int, int)
// calc.add(1.0, 2.0);  // Вызовет double add(double, double)

Пример C# (Перегрузка методов):

public class Calculator
{
    public int Add(int a, int b) { return a + b; }
    public double Add(double a, double b) { return a + b; } // Перегрузка
    public int Add(int a, int b, int c) { return a + b + c; } // Еще одна перегрузка
}
// Использование:
// Calculator calc = new Calculator();
// calc.Add(1, 2);      // Вызовет int Add(int, int)
// calc.Add(1.0, 2.0);  // Вызовет double Add(double, double)

• Перегрузка операторов (Operator Overloading): Позволяет изменить стандартное поведение операторов (например, +, -, *, /, ==, !=) для пользовательских типов данных (классов). Это делает код более интуитивным и читаемым при работе с объектами.

Пример C++ (Перегрузка оператора +):

class Vector {
public:
    int x, y;
    Vector(int x_val = 0, int y_val = 0) : x(x_val), y(y_val) {}
    Vector operator+(const Vector& other) const { // Перегрузка оператора +
        return Vector(x + other.x, y + other.y);
    }
};
// Использование:
// Vector v1(1, 2);
// Vector v2(3, 4);
// Vector v3 = v1 + v2; // v3 будет (4, 6)

Пример C# (Перегрузка оператора +):

public class Vector
{
    public int X { get; set; }
    public int Y { get; set; }
    public Vector(int x_val = 0, int y_val = 0) { X = x_val; Y = y_val; }
    public static Vector operator +(Vector v1, Vector v2) // Перегрузка оператора +
    {
        return new Vector(v1.X + v2.X, v1.Y + v2.Y);
    }
}
// Использование:
// Vector v1 = new Vector(1, 2);
// Vector v2 = new Vector(3, 4);
// Vector v3 = v1 + v2; // v3 будет (4, 6)

Динамический полиморфизм: Виртуальные функции и переопределение методов

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

Реализация Динамического Полиморфизма в C++:

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

Техническая реализация (VMT/Vtable и V-указатели):
Динамический полиморфизм в C++ реализуется на низком уровне с использованием Таблицы виртуальных методов (VMT или Vtable).

1. Vtable: Каждому классу, содержащему хотя бы одну виртуальную функцию, компилятор создает статическую таблицу (Vtable). Эта таблица содержит указатели на реализации виртуальных функций для этого конкретного класса.
2. V-указатель (vpointer): Каждый объект класса, содержащего виртуальные функции, несет в себе скрытый V-указатель. Этот V-указатель инициализируется при создании объекта и указывает на Vtable того класса, к которому фактически принадлежит объект.
3. Вызов виртуальной функции: Когда виртуальная функция вызывается через указатель или ссылку на базовый класс, компилятор генерирует код, который сначала использует V-указатель объекта для получения адреса Vtable, а затем по смещению в Vtable находит адрес нужной виртуальной функции и вызывает ее. Таким образом, во время выполнения вызов направляется к правильной (наиболее производной) реализации.

Пример C++ (Виртуальные функции):

#include <iostream>

class Animal {
public:
    virtual void makeSound() { // Виртуальный метод
        std::cout << "Animal makes a sound." << std::endl;
    }
};

class Dog : public Animal {
public:
    void makeSound() override { // Переопределение виртуального метода
        std::cout << "Woof!" << std::endl;
    }
};

class Cat : public Animal {
public:
    void makeSound() override { // Переопределение виртуального метода
        std::cout << "Meow!" << std::endl;
    }
};

// Использование:
// Animal* myAnimal = new Dog();
// myAnimal->makeSound(); // Выведет "Woof!" благодаря динамическому полиморфизму
// delete myAnimal;

Чисто виртуальная функция (Pure Virtual Function) в C++:
Это метод, объявленный в базовом классе с синтаксисом = 0 (например, virtual float area() = 0;), и не имеющий тела (реализации) в этом базовом классе.

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

Реализация Динамического Полиморфизма в C#:

В C# динамический полиморфизм реализуется с использованием ключевых слов virtual и override.

• Метод в базовом классе, который предполагается переопределять, объявляется с ключевым словом virtual.
• В классе-потомке, который предоставляет свою специфическую реализацию, метод объявляется с ключевым словом override.
• Для создания абстрактного метода (аналог чисто виртуальной функции в C++) используется ключевое слово abstract в абстрактном классе. Такой метод не имеет реализации в базовом классе и должен быть обязательно переопределен в неабстрактном потомке.

Пример C# (Виртуальные и переопределенные методы):

using System;

public class Animal
{
    public virtual void MakeSound() // Виртуальный метод
    {
        Console.WriteLine("Animal makes a sound.");
    }
}

public class Dog : Animal
{
    public override void MakeSound() // Переопределение виртуального метода
    {
        Console.WriteLine("Woof!");
    }
}

public class Cat : Animal
{
    public override void MakeSound() // Переопределение виртуального метода
    {
        Console.WriteLine("Meow!");
    }
}

// Использование:
// Animal myAnimal = new Dog();
// myAnimal.MakeSound(); // Выведет "Woof!"

Сравнение подходов C++ и C# к динамическому полиморфизму:

Характеристика	C++	C#
Ключевые слова	virtual (в базовом классе), = 0 (для чисто виртуальных)	virtual (в базовом), override (в производном), abstract (для абстрактных)
Механизм	Vtable и V-указатели (управляется компилятором)	Методы в таблице методов класса (CLR/Runtime)
Абстрактные классы/методы	Используют чисто виртуальные функции (= 0)	Используют ключевое слово abstract
Наследование	Поддерживает множественное наследование классов (с «проблемой ромба»)	Только одиночное наследование классов, множественная реализация интерфейсов
Управление памятью	Ручное (new/delete) или умные указатели	Автоматическая сборка мусора (GC)

Фундаментальное различие заключается в том, что C++ полагается на механизмы компилятора и компоновщика (Vtable), работая ближе к аппаратному обеспечению, что дает больше контроля, но требует большей ответственности. C# же реализует полиморфизм на уровне Common Language Runtime (CLR), что упрощает управление, но добавляет уровень абстракции. Оба подхода эффективны, но имеют свои компромиссы в производительности и гибкости.

Управление Памятью и Жизненный Цикл Объекта

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

Конструкторы: Инициализация объектов

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

Типы конструкторов:

1. Конструктор по умолчанию (Default Constructor): Не принимает аргументов. Если программист не определяет ни одного конструктора, компилятор C++ генерирует публичный конструктор по умолчанию (если нет пользовательских конструкторов). В C# конструктор по умолчанию генерируется автоматически, если не определен ни один конструктор.
2. Конструктор с параметрами (Parameterized Constructor): Принимает один или несколько аргументов для инициализации полей объекта конкретными значениями.
3. Конструктор копирования (Copy Constructor): Специальный конструктор, который используется для создания нового объекта как копии уже существующего объекта того же класса. В C++ он часто имеет вид MyClass(const MyClass& other). В C# копирование объектов обычно осуществляется путем создания нового объекта и поочередного присваивания значений полей, либо через реализацию интерфейса ICloneable.

Примеры кода (Конструкторы):

C++:

#include <iostream>
#include <string>

class User {
public:
    std::string name;
    int age;

    // Конструктор по умолчанию
    User() : name("Guest"), age(0) {
        std::cout << "Default constructor called." << std::endl;
    }

    // Конструктор с параметрами
    User(const std::string& n, int a) : name(n), age(a) {
        std::cout << "Parameterized constructor called for " << name << std::endl;
    }

    // Конструктор копирования
    User(const User& other) : name(other.name + " (copy)"), age(other.age) {
        std::cout << "Copy constructor called for " << name << std::endl;
    }
};
// Использование:
// User u1; // Default
// User u2("Alice", 30); // Parameterized
// User u3 = u2; // Copy

C#:

using System;

public class User
{
    public string Name { get; set; }
    public int Age { get; set; }

    // Конструктор по умолчанию (неявно присутствует, если нет других, или явно)
    public User()
    {
        Name = "Guest";
        Age = 0;
        Console.WriteLine("Default constructor called.");
    }

    // Конструктор с параметрами
    public User(string name, int age)
    {
        Name = name;
        Age = age;
        Console.WriteLine($"Parameterized constructor called for {Name}");
    }

    // Пример "копирующего" конструктора в C# (не стандартизирован как в C++)
    public User(User other)
    {
        Name = other.Name + " (copy)";
        Age = other.Age;
        Console.WriteLine($"Copy constructor called for {Name}");
    }
}
// Использование:
// User u1 = new User(); // Default
// User u2 = new User("Bob", 25); // Parameterized
// User u3 = new User(u2); // "Copying" constructor

Управление памятью в C++: Ручное освобождение и деструкторы

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

• Ручное управление памятью (new, delete):
  В C++ для динамического выделения памяти под объекты в куче (heap) используется оператор new. Это позволяет создавать объекты, жизненный цикл которых не ограничен областью видимости. Однако, ответственность за освобождение этой памяти лежит полностью на программисте, который должен вызвать оператор delete для каждого объекта, созданного с помощью new. Невыполнение этого требования приводит к утечкам памяти.

• Деструктор (~MyClass()):
  Деструктор — это специальный метод класса в C++, который автоматически вызывается перед уничтожением объекта. Он предназначен для освобождения ресурсов, занятых объектом, таких как динамически выделенная память, файловые дескрипторы, сетевые соединения и т.д.
  • Для объектов, созданных на стеке (локальные переменные), деструктор вызывается при выходе объекта из области видимости.
  • Для динамически созданных объектов (new), деструктор вызывается, когда программист явно вызывает delete для указателя на этот объект.

Пример C++ (Деструктор):

class MyResource {
public:
    int* data;
    MyResource() {
        data = new int[10]; // Выделяем память
        std::cout << "MyResource constructed, memory allocated." << std::endl;
    }
    ~MyResource() { // Деструктор
        delete[] data; // Освобождаем память
        std::cout << "MyResource destructed, memory freed." << std::endl;
    }
};
// Использование:
// {
//     MyResource res; // Объект на стеке, деструктор вызовется при выходе из блока
// }
// MyResource* p_res = new MyResource();
// delete p_res; // Деструктор вызовется явно

• RAII (Resource Acquisition Is Initialization) и умные указатели:
  Чтобы минимизировать риски утечек памяти при ручном управлении, современный C++ (начиная с C++11) активно использует идиому RAII (Resource Acquisition Is Initialization). Суть RAII заключается в том, что любой ресурс (память, файл, мьютекс) приобретается в конструкторе объекта и освобождается в его деструкторе. Это гарантирует, что ресурс будет освобожден автоматически при уничтожении объекта, даже если произойдет исключение.
  Классическим примером реализации RAII являются умные указатели:
  • std::unique_ptr: Обеспечивает исключительное владение ресурсом. Только один unique_ptr может владеть данным объектом. При уничтожении unique_ptr ресурс освобождается.
  • std::shared_ptr: Реализует совместное владение ресурсом с подсчетом ссылок. Ресурс освобождается только тогда, когда количество shared_ptr, указывающих на него, становится равным нулю.

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

Пример C++ (Умные указатели):

#include <memory> // Для unique_ptr и shared_ptr

// ... (класс MyResource как выше)

// Использование unique_ptr:
// {
//     std::unique_ptr<MyResource> res_ptr = std::make_unique<MyResource>();
//     // res_ptr автоматически освободит ресурс при выходе из области видимости
// } // Здесь будет вызван деструктор MyResource

// Использование shared_ptr:
// std::shared_ptr<MyResource> shared_res1 = std::make_shared<MyResource>();
// {
//     std::shared_ptr<MyResource> shared_res2 = shared_res1; // Оба shared_ptr владеют одним ресурсом
// } // shared_res2 выходит из области видимости, но ресурс НЕ освобождается (счетчик = 1)
// // Здесь будет вызван деструктор MyResource, когда shared_res1 выйдет из области видимости

Управление памятью в C#: Автоматическая сборка мусора (GC)

В отличие от C++, C# (и платформа .NET) использует систему автоматической сборки мусора (Garbage Collection, GC). Это фундаментальное различие. GC автоматически отслеживает объекты, созданные в управляемой куче, и освобождает память, занятую теми из них, на которые больше нет активных ссылок. Это значительно упрощает разработку, поскольку снимает с программиста бремя ручного управления памятью, снижая риск утечек и ошибок, связанных с памятью.

Преимущества GC:

• Упрощение кода и повышение производительности разработчика.
• Устранение целого класса ошибок, связанных с утечками памяти и «висячими» указателями.
• Повышение безопасности и стабильности приложения.

Недостатки GC:

• Недетерминированное освобождение памяти: GC работает в фоновом режиме, и нет гарантии, когда именно объект будет собран. Это может быть проблемой для ресурсов, которые должны быть освобождены немедленно (например, файловые дескрипторы).
• Внесение пауз (stop-the-world) во время работы GC, что может влиять на отзывчивость высокопроизводительных приложений (хотя современные GC минимизируют этот эффект).
• Потенциально больший расход памяти, так как GC может сохранять объекты дольше, чем они фактически нужны.

Поколенческая сборка мусора (Generational Garbage Collection) в .NET:
Современный GC в .NET использует сложную стратегию, называемую Поколенческой сборкой мусора, которая основана на наблюдении, что большинство объектов «умирают молодыми», и лишь немногие «доживают» до зрелого возраста. Управляемая куча разделена на три поколения:

• Поколение 0 (Gen 0): Самое молодое поколение. Новые объекты выделяются здесь. Большая часть объектов в Gen 0 быстро становятся недостижимыми и собираются очень часто.
• Поколение 1 (Gen 1): Объекты, выжившие после сборки в Gen 0, перемещаются в Gen 1. Сборка в Gen 1 происходит реже, чем в Gen 0.
• Поколение 2 (Gen 2): Самое старое поколение. Объекты, выжившие после сборки в Gen 1, перемещаются в Gen 2. Сборка в Gen 2 происходит редко и является наиболее затратной.
• Куча крупных объектов (Large Object Heap, LOH): Отдельная область для объектов, размер которых превышает определенный порог (например, 85 КБ). LOH не подвергается компактной дефрагментации так часто, как другие поколения, из-за высокой стоимости перемещения больших блоков памяти.

Такая стратегия позволяет GC оптимизировать процесс, фокусируясь на «молодых» поколениях, где вероятность нахождения мусора выше, и тем самым сокращая время пауз.

Деструкторы (финализаторы) и IDisposable в C#: Управляемые и неуправляемые ресурсы

В мире C# и .NET важно четко различать два типа ресурсов:

• Управляемые ресурсы: Это объекты, которые создаются в управляемой куче .NET и полностью управляются сборщиком мусора. Их жизненным циклом занимается GC.
• Неуправляемые ресурсы: Это ресурсы, которые находятся за пределами контроля .NET Framework. Примеры включают файловые дескрипторы, сетевые сокеты, указатели на память, выделенную через WinAPI, дескрипторы окон, COM-объекты. GC не знает, как освободить эти ресурсы.

Деструктор (Финализатор) в C# (~MyClass()):
Деструктор в C# синтаксически похож на C++-деструктор, но его поведение принципиально иное. Он фактически является переопределением метода Finalize() базового класса System.Object.

• Финализатор не вызывается немедленно при потере ссылок на объект. Вместо этого объект, имеющий финализатор, добавляется в специальную очередь (finalization queue).
• Когда GC запускается и обнаруживает объекты с финализаторами, он перемещает их из обычной кучи в специальную очередь для финализации.
• Затем отдельный поток (финализаторный поток) вызывает Finalize() для этих объектов.
• После вызова Finalize(), на следующем цикле сборки мусора, память объекта окончательно освобождается.
  Это означает, что финализаторы обеспечивают недетерминированное освобождение неуправляемых ресурсов. Нет гарантии, когда именно финализатор будет вызван, что может привести к длительному удержанию ценных системных ресурсов.

Интерфейс IDisposable и конструкция using:
Для детерминированного и немедленного освобождения неуправляемых ресурсов в C# предпочтительным решением является реализация интерфейса System.IDisposable (так называемый «Dispose Pattern»).

• Интерфейс IDisposable содержит единственный метод: void Dispose().
• В этом методе Dispose() программист явно освобождает все неуправляемые ресурсы (например, закрывает файл, освобождает GDI-объекты).
• Для гарантированного вызова Dispose() используется конструкция using. Блок using обеспечивает, что метод Dispose() будет вызван автоматически, когда объект выходит из области видимости, даже если в блоке возникнет исключение.

Пример C# (IDisposable и using):

using System;
using System.IO;

public class MyFileHandler : IDisposable
{
    private FileStream _fileStream;

    public MyFileHandler(string filePath)
    {
        _fileStream = new FileStream(filePath, FileMode.OpenOrCreate);
        Console.WriteLine($"File '{filePath}' opened.");
    }

    public void WriteToFile(string text)
    {
        if (_fileStream != null)
        {
            byte[] buffer = System.Text.Encoding.UTF8.GetBytes(text);
            _fileStream.Write(buffer, 0, buffer.Length);
            Console.WriteLine($"Wrote '{text}' to file.");
        }
    }

    // Метод Dispose() для детерминированного освобождения неуправляемых ресурсов
    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this); // Предотвращаем вызов финализатора
    }

    protected virtual void Dispose(bool disposing)
    {
        if (disposing)
        {
            // Освобождаем управляемые ресурсы, если есть
            if (_fileStream != null)
            {
                _fileStream.Dispose(); // Закрываем FileStream
                _fileStream = null;
            }
        }
        // Здесь освобождаем неуправляемые ресурсы (если бы они были напрямую, например, WinAPI HANDLE)
        Console.WriteLine("Unmanaged resources disposed.");
    }

    // Финализатор (не рекомендуется для детерминированного освобождения)
    ~MyFileHandler()
    {
        Console.WriteLine("Finalizer called (non-deterministic).");
        Dispose(false); // Освобождаем только неуправляемые ресурсы
    }
}

// Использование:
// using (MyFileHandler handler = new MyFileHandler("log.txt"))
// {
//     handler.WriteToFile("Hello, world!");
// } // Здесь автоматически вызывается Dispose(), файл закрывается.
// // Если бы не было 'using', финализатор мог бы сработать намного позже.

GC.SuppressFinalize(this) в методе Dispose() используется для того, чтобы после детерминированного освобождения ресурсов через Dispose() сборщик мусора не тратил время на вызов финализатора для этого объекта, так как ресурсы уже были освобождены.

В итоге, хотя C# имеет GC, для работы с неуправляемыми ресурсами требуется дисциплинированное использование IDisposable и using, чтобы обеспечить своевременное и надежное освобождение системных ресурсов, в то время как C++ полагается на RAII и умные указатели для достижения аналогичных целей.

Интеграция ООП с Системным Программированием Windows

Разработка приложений для операционной системы Windows, особенно на низком уровне с использованием WinAPI, традиционно ассоциировалась с процедурным подходом. Однако современные фреймворки и языки, такие как C++ с MFC/ATL и C# с WinForms/WPF, демонстрируют мощную интеграцию принципов ООП с системным программированием, позволяя создавать сложные и надежные GUI-приложения и многопоточные сервисы.

Событийно-ориентированная модель и цикл обработки сообщений WinAPI

Операционная система Windows основана на событийно-ориентированной модели. Это означает, что приложение большую часть времени находится в режиме ожидания, реагируя на различные события, инициируемые пользователем (нажатия клавиш, движение мыши), системой (перерисовка окна, таймеры) или другими приложениями.

Центральным элементом этой модели является Цикл обработки сообщений (Message Loop), который работает в каждом потоке, владеющем окнами. Его функции:

• GetMessage(): Эта функция блокирует выполнение потока до тех пор, пока в его очередь сообщений не поступит новое сообщение. После получения сообщения она извлекает его и заполняет структуру MSG.
• PeekMessage(): В отличие от GetMessage(), PeekMessage() не блокирует поток. Она проверяет наличие сообщений в очереди и, если они есть, извлекает их. Если сообщений нет, она возвращает управление немедленно, позволяя потоку выполнять другие задачи.
• Структура MSG: Основная структура, описывающая сообщение Windows. Она содержит:
  • hwnd: Дескриптор окна, которому адресовано сообщение.
  • message: Идентификатор сообщения (например, WM_LBUTTONDOWN для нажатия левой кнопки мыши, WM_PAINT для запроса на перерисовку окна).
  • wParam, lParam: Дополнительные параметры, специфичные для каждого типа сообщения.

После извлечения сообщения из очереди оно обычно передается функции DispatchMessage(), которая вызывает оконную процедуру (Window Procedure) соответствующего окна. Оконная процедура — это функция, которая содержит switch-оператор для обработки различных WM_* сообщений.

Интеграция с ООП:
В объектно-ориентированных фреймворках этот низкоуровневый, процедурный механизм искусно абстрагируется и инкапсулируется:

• MFC (Microsoft Foundation Classes) в C++: Классы CWnd, CDialog, CFrameWnd инкапсулируют дескриптор окна (HWND) и содержат виртуальные методы для обработки сообщений (например, OnPaint(), OnLButtonDown()). Разработчик переопределяет эти методы, чтобы добавить свою логику, не работая напрямую с switch-оператором и WM_ константами.
• WinForms/WPF в C# (.NET): Здесь абстракция еще глубже. Низкоуровневые сообщения WinAPI трансформируются в высокоуровневые события .NET (например, MouseEventArgs, KeyEventArgs). Разработчик подписывается на эти события через делегаты, а обработчики событий реализуются как обычные методы класса формы или элемента управления.
  Например, вместо обработки WM_LBUTTONDOWN в оконной процедуре, в WinForms вы просто подписываетесь на событие MouseDown компонента, а обработчик private void button1_MouseDown(object sender, MouseEventArgs e) получает уже разобранные параметры (координаты клика, нажатые кнопки) в удобном объектном виде.

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

Многопоточность: Создание и управление потоками

Потоки (Threads) являются основными единицами выполнения в операционной системе Windows. Процесс может содержать один или несколько потоков. Каждый поток имеет свой собственный стек вызовов, набор регистров и приоритет, но разделяет адресное пространство и системные ресурсы с другими потоками того же процесса.

• WinAPI (CreateThread()): На низком уровне в WinAPI поток создается с помощью функции CreateThread(). Она принимает адрес функции, которая будет служить точкой входа для нового потока, и возвращает дескриптор потока.

  HANDLE hThread = CreateThread(
      NULL,              // default security attributes
      0,                 // default stack size
      MyThreadFunction,  // thread start function
      NULL,              // no thread function argument
      0,                 // default creation flags
      NULL);             // receive thread identifier
  

• ООП-языки (C#, C++ с std::thread):
  • C# (System.Threading.Thread, Task, ThreadPool): В C# есть класс Thread для низкоуровневого управления потоками, но предпочтительнее использовать более высокоуровневые абстракции, такие как Task Parallel Library (TPL) с Task и Task<TResult> для асинхронных операций, а также ThreadPool для управления пулом потоков, что позволяет более эффективно использовать ресурсы.
  • C++ (std::thread): Современный C++ (начиная с C++11) предоставляет класс std::thread как платформенно-независимую оболочку над потоками ОС, позволяющую создавать и управлять ими в объектно-ориентированном стиле.

    #include <thread>
    #include <iostream>
    
    void my_function() {
        std::cout << "Hello from thread!" << std::endl;
    }
    
    // std::thread t(my_function);
    // t.join(); // Ожидание завершения потока
    

Синхронизация потоков: Механизмы и особенности применения

Когда несколько потоков работают в одном адресном пространстве и обращаются к общим данным, возникает проблема состояния гонки (race condition). Для предотвращения повреждения данных и обеспечения когерентности необходима синхронизация потоков. Это механизмы, которые управляют совместным доступом к общим ресурсам (критическим секциям) и координируют выполнение потоков.

Объекты синхронизации WinAPI:
Windows предоставляет набор мощных объектов ядра для синхронизации, дескрипторы которых могут использоваться для ожидания и координации:

• Мьютексы (Mutexes): Объект ядра, который обеспечивает взаимоисключающий доступ к ресурсу. Только один поток может владеть мьютексом в любой момент времени. Мьютексы могут использоваться для синхронизации потоков в пределах одного процесса, а также между различными процессами. Они относительно «тяжелые», так как всегда требуют переключения в режим ядра (kernel mode).
• Семафоры (Semaphores): Объект ядра, который управляет доступом к ограниченному пулу ресурсов. Семафор имеет счетчик, который уменьшается при захвате ресурса и увеличивается при его освобождении. Поток может захватить ресурс, только если счетчик больше нуля. Семафоры полезны для управления доступом к нескольким экземплярам одного ресурса.
• События (Events): Объекты ядра, используемые для сигнализации потокам о наступлении определенного события. События бывают двух типов:
  • Ручные (Manual-Reset Events): Требуют явного сброса состояния после сигнализации.
  • Автоматические (Auto-Reset Events): Автоматически сбрасываются в несигнальное состояние после освобождения одного ожидающего потока.
• Критические секции (Critical Sections): Более легковесный механизм синхронизации, предназначенный для использования только внутри одного процесса. Они не являются объектами ядра, а реализованы в пользовательском режиме.

Сравнительный анализ Критических секций и Мьютексов:

Характеристика	Критическая секция	Мьютекс
Область действия	Только внутри одного процесса	Между процессами и внутри процесса
Реализация	Пользовательский режим (user-mode), с использованием спин-блокировки	Объект ядра (kernel object)
Производительность	Выше для uncontended acquire (нет конфликта), так как избегает перехода в ядро	Ниже, так как всегда требует системного вызова (context switch)
Использование памяти	Меньше (только структура CRITICAL_SECTION)	Больше (объект ядра)
Защита от дедлоков	Не поддерживает рекурсивное взятие блокировки (в некоторых реализациях)	Поддерживает рекурсивное взятие блокировки (потоком-владельцем)

Преимущества Критических секций: Когда нет конфликта за критическую секцию (uncontended acquire), она использует спин-блокировку в пользовательском режиме (user-mode spin lock). Это означает, что поток просто «крутится» в цикле, проверяя, не освободилась ли блокировка, не переключаясь в режим ядра. Это значительно быстрее, чем системный вызов, который всегда требуется для мьютекса, поскольку переход в режим ядра является дорогостоящей операцией. Только если спин-блокировка не срабатывает в течение короткого времени, критическая секция переходит в режим ядра и ожидает там.

Разбор «слепой зоны»: Проблема WaitForSingleObject для оконных потоков и её решение с использованием MsgWaitForMultipleObjects

Одной из распространенных «слепых зон» при многопоточном программировании в Windows является неправильное использование функций ожидания для потоков, которые владеют окнами (например, UI-потоков).

• Функция WaitForSingleObject блокирует выполнение потока до тех пор, пока указанный объект синхронизации не перейдет в сигнальное состояние. Критическая проблема заключается в том, что WaitForSingleObject полностью останавливает обработку сообщений Windows для этого потока.
• Если поток владеет окном и вызовет WaitForSingleObject, он перестанет обрабатывать WM_PAINT (перерисовка), WM_COMMAND (нажатия кнопок) и другие сообщения. Это приводит к зависанию интерфейса (UI), окно перестает отвечать, не перерисовывается, и пользователь видит «белое» или «неотвечающее» окно.

Решение: MsgWaitForMultipleObjects или MsgWaitForMultipleObjectsEx
Для потоков, владеющих окнами, необходимо использовать функцию MsgWaitForMultipleObjects (или MsgWaitForMultipleObjectsEx). Эта функция позволяет потоку ожидать один или несколько объектов синхронизации, но при этом она также включает в условия выхода из ожидания наличие сообщений Windows в очереди потока.
Если в очереди появляются сообщения (например, WM_PAINT), MsgWaitForMultipleObjects возвращает управление, позволяя потоку извлечь и обработать эти сообщения, а затем, при необходимости, снова войти в режим ожидания. Это гарантирует, что UI остается отзывчивым, пока поток ожидает завершения асинхронной операции или освобождения ресурса. В противном случае, риск создания неотзывчивых приложений значительно возрастает.

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

Заключение

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

Мы деконструировали три столпа ООП — инкапсуляцию, наследование и полиморфизм, — подчеркивая, как они проявляются в синтаксисе и архитектуре C++ и C#. Были рассмотрены тонкости управления памятью, от ручного контроля с деструкторами и умными указателями в C++ до автоматической поколенческой сборки мусора в C# и жизненно важной роли IDisposable для неуправляемых ресурсов. Наконец, мы интегрировали эти концепции с системным программированием Windows, показав, как событийная модель, потоки и механизмы синхронизации (мьютексы, критические секции) преобразуются в объектно-ориентированные абстракции, позволяя создавать отзывчивые и надежные приложения.

Для современного студента и будущего специалиста в области ИТ критически важно не просто знать определения этих принципов, но и глубоко понимать их механизмы, различия в реализации между языками и потенциальные «подводные камни». Это знание позволяет не только успешно сдавать экзамены, но и принимать обоснованные архитектурные решения, писать эффективный, безопасный и легко сопровождаемый код. Понимание как высокоуровневых концепций, так и низкоуровневых механизмов является ключом к мастерству в разработке программного обеспечения, позволяя создавать решения, которые будут выдерживать испытание временем и адаптироваться к постоянно меняющимся требованиям.

Список использованной литературы

1. История ООП: когда и зачем появилось? // sky.pro
2. История создания, основные принципы и преимущества ООП // php.zone
3. Парадигмы программирования // znanierussia.ru
4. Инкапсуляция, полиморфизм, наследование // codenet.ru
5. Эволюция парадигмы программирования // osp.ru
6. C#. Деструктор. «Сборка мусора // BestProg
7. Программирование Object-Oriented (C#) // Microsoft Learn
8. Руководство C# | Сборка мусора и деструкторы // professorweb.ru
9. Статический и динамический полиморфизм в C++ // Habr
10. Шилдт Г. C# 4.0: полное руководство. “Сборка мусора” и применение деструкторов // wikireading.ru
11. Основные принципы объектно-ориентированного программирования. Инкапсуляция, полиморфизм, наследование // narod.ru
12. Полиморфизм в языке программирования C# // unetway.com
13. Реализация динамического полиморфизма в C++ // labex.io
14. Лекция 2 Основные принципы ООП: инкапсуляция, наследование, полиморфизм // zhanibekov.edu.kz
15. Полиморфизм // energyed.ru
16. Сборка мусора и финализаторы — C# // c-sharp.pro
17. Сборщик мусора на С++ // Habr
18. Полиморфизм в С++ // Демо-занятие курса «C++ Developer» // youtube.com
19. Синхронизация выполнения нескольких потоков — Win32 apps // Microsoft Learn
20. Управление потоком в WinAPI [СИ] // stackoverflow.com
21. Организация рабочих потоков: синхронизационный канал // Habr
22. Синхронизация процессов при работе с Windows // compress.ru
23. Windows и C++ — Синхронизация пула потоков // Microsoft Learn