📌 Что такое паттерны проектирования?

💬 Спрашивают в 11% собеседований

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

🤔 Основные категории паттернов проектирования

1️⃣ Порождающие паттерны (Creational Patterns): Эти паттерны связаны с созданием объектов, что позволяет скрыть сложность создания объектов и повысить гибкость системы.

➕ Примеры: Singleton, Factory Method, Abstract Factory, Builder, Prototype.

2️⃣ Структурные паттерны (Structural Patterns): Эти паттерны описывают, как классы и объекты могут быть объединены для формирования больших структур.

➕ Примеры: Adapter, Composite, Proxy, Flyweight, Facade, Bridge, Decorator.

🤔 Примеры паттернов проектирования

🤔 Singleton (Порождающий паттерн)

Обеспечивает создание единственного экземпляра класса и предоставляет глобальную точку доступа к этому экземпляру.

public class Singleton
{
    private static Singleton instance;

    private Singleton() { }

    public static Singleton Instance
    {
        get
        {
            if (instance == null)
            {
                instance = new Singleton();
            }
            return instance;
        }
    }
}

🤔 Factory Method (Порождающий паттерн)

Определяет интерфейс для создания объекта, но позволяет подклассам изменить тип создаваемого объекта.

public abstract class Product { }

public class ConcreteProductA : Product { }

public class ConcreteProductB : Product { }

public abstract class Creator
{
    public abstract Product FactoryMethod();
}

public class ConcreteCreatorA : Creator
{
    public override Product FactoryMethod()
    {
        return new ConcreteProductA();
    }
}

public class ConcreteCreatorB : Creator
{
    public override Product FactoryMethod()
    {
        return new ConcreteProductB();
    }
}

🤔 Adapter (Структурный паттерн)

Позволяет объектам с несовместимыми интерфейсами работать вместе.

public interface ITarget
{
    void Request();
}

public class Adaptee
{
    public void SpecificRequest()
    {
        Console.WriteLine("Specific request");
    }
}

public class Adapter : ITarget
{
    private readonly Adaptee _adaptee;

    public Adapter(Adaptee adaptee)
    {
        _adaptee = adaptee;
    }

    public void Request()
    {
        _adaptee.SpecificRequest();
    }
}

🤔 Observer (Поведенческий паттерн)

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

public interface IObserver
{
    void Update();
}

public class ConcreteObserver : IObserver
{
    public void Update()
    {
        Console.WriteLine("Observer updated");
    }
}

public class Subject
{
    private readonly List<IObserver> observers = new List<IObserver>();

    public void Attach(IObserver observer)
    {
        observers.Add(observer);
    }

    public void Detach(IObserver observer)
    {
        observers.Remove(observer);
    }

    public void Notify()
    {
        foreach (var observer in observers)
        {
            observer.Update();
        }
    }
}

🤔 Краткий ответ

Паттерны проектирования — это проверенные решения общих проблем в разработке программного обеспечения. Они делятся на три категории: порождающие (Singleton, Factory Method), структурные (Adapter, Composite) и поведенческие (Observer, Strategy). Использование паттернов улучшает структуру кода, делает его более читаемым и гибким.

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Какие есть паттерны проектирования?

💬 Спрашивают в 11% собеседований

Паттерны проектирования — это шаблоны для решения общих проблем при разработке ПО. Они делятся на три категории:

🤔 Порождающие (Creational)

➕ Singleton: Один экземпляр класса.

➕ Factory Method: Создание объектов через методы.

➕ Abstract Factory: Семейства связанных объектов.

➕ Builder: Пошаговое создание сложных объектов.

➕ Prototype: Клонирование объектов.

🤔 Структурные (Structural)

➕ Adapter: Преобразование интерфейсов.

➕ Bridge: Разделение абстракции и реализации.

➕ Composite: Деревья объектов.

➕ Decorator: Добавление поведения объектам.

➕ Facade: Упрощение интерфейсов.

➕ Flyweight: Разделение мелких объектов.

➕ Proxy: Заместитель объектов.

🤔 Поведенческие (Behavioral)

➕ Observer: Оповещение об изменениях.

➕ Strategy: Замена алгоритмов.

➕ Command: Инкапсуляция запросов.

➕ Iterator: Последовательный доступ.

➕ Mediator: Посредник для взаимодействия.

➕ State: Смена поведения в зависимости от состояния.

➕ Chain of Responsibility: Цепочка обработчиков.

➕ Visitor: Добавление операций к объектам.

➕ Template Method: Скелет алгоритма.

🤔 Краткий ответ

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

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 В чем отличие монолитной и микросервисной архитектуре на практике?

💬 Спрашивают в 11% собеседований

Монолитная и микросервисная архитектуры представляют собой два разных подхода к построению программных систем. Рассмотрим ключевые отличия между ними на практике:

🤔 Монолитная архитектура

Определение:

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

Особенности:

1️⃣ Единый код:

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

➕ Пример: Веб-приложение, где UI, бизнес-логика и доступ к данным находятся в одном проекте.

2️⃣ Разработка и деплой:

➕ Разработка может быть проще на начальном этапе, так как все компоненты находятся в одном проекте.

➕ Деплой представляет собой единое целое: обновление требует полного перезапуска приложения.

3️⃣ Тестирование:

➕ Процесс тестирования проще, так как все находится в одном проекте.

➕ Тесты могут покрывать весь функционал приложения сразу.

4️⃣ Масштабирование:

➕ Масштабирование происходит путем клонирования всего приложения (вертикальное масштабирование).

➕ Ограничено возможностями одного сервера.

5️⃣ Связность:

➕ Высокая степень связности между компонентами может привести к трудностям в поддержке и модификации.

➕ Изменение одного компонента может потребовать пересмотра всего приложения.

🤔 Микросервисная архитектура

Определение:

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

Особенности:

1️⃣ Разделение кода:

➕ Логика приложения разделена на отдельные сервисы, каждый из которых может разрабатываться, тестироваться и деплоиться независимо.

➕ Пример: Интернет-магазин с отдельными сервисами для управления товарами, заказами, платежами и пользователями.

2️⃣ Разработка и деплой:

➕ Разработка может быть сложнее из-за необходимости координации между командами.

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

3️⃣ Тестирование:

➕ Тестирование может быть сложнее, так как необходимо тестировать взаимодействие между сервисами.

➕ Поддержка контрактного тестирования и других методологий для обеспечения совместимости сервисов.

4️⃣ Масштабирование:

➕ Масштабирование происходит горизонтально: можно масштабировать только те сервисы, которые испытывают высокую нагрузку.

➕ Более гибкое и эффективное использование ресурсов.

5️⃣ Связность:

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

➕ Изменение одного сервиса не требует изменения других, что уменьшает риск.

🤔 Пример на практике

Монолит:

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

Микросервисы:

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

🤔 Краткий ответ

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

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Внешние ключи должны быть в базе данных?

💬 Спрашивают в 11% собеседований

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

🤔 Зачем нужны внешние ключи

1️⃣ Целостность данных:

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

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

2️⃣ Упрощение запросов:

➕ Внешние ключи облегчают написание запросов SQL, которые объединяют данные из нескольких таблиц. Они обеспечивают логическую связь, которая позволяет объединять таблицы в запросах.

➕ Пример: Получение всех заказов вместе с информацией о клиенте, сделавшем заказ.

3️⃣ Поддержка каскадных операций:

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

➕ Пример: При удалении клиента можно настроить каскадное удаление всех его заказов.

4️⃣ Улучшение целостности данных:

➕ Они предотвращают некорректные данные, такие как "висячие" ссылки, когда запись в одной таблице ссылается на несуществующую запись в другой таблице.

➕ Пример: Невозможно добавить заказ в таблицу Orders, если нет соответствующего клиента в таблице Customers.

🤔 Как использовать внешние ключи

1️⃣ Создание внешнего ключа:

➕ Внешний ключ создается при создании таблицы или добавляется позже с помощью команды ALTER TABLE.

➕ Пример создания внешнего ключа при создании таблицы:

     CREATE TABLE Orders (
         OrderID int PRIMARY KEY,
         OrderDate datetime,
         CustomerID int,
         FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID)
     );
     

2️⃣ Добавление внешнего ключа в существующую таблицу:

➕ Если таблица уже существует, внешний ключ можно добавить с помощью команды ALTER TABLE.

➕ Пример:

     ALTER TABLE Orders
     ADD CONSTRAINT FK_CustomerOrder
     FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID);
     

3️⃣ Каскадные операции:

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

➕ Пример настройки каскадного удаления:

     CREATE TABLE Orders (
         OrderID int PRIMARY KEY,
         OrderDate datetime,
         CustomerID int,
         FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID)
         ON DELETE CASCADE
     );
     

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

🤔 Пример 1: Базовая установка внешнего ключа

CREATE TABLE Customers (
    CustomerID int PRIMARY KEY,
    CustomerName varchar(255)
);

CREATE TABLE Orders (
    OrderID int PRIMARY KEY,
    OrderDate datetime,
    CustomerID int,
    FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID)
);

🤔 Пример 2: Каскадное удаление

CREATE TABLE Orders (
    OrderID int PRIMARY KEY,
    OrderDate datetime,
    CustomerID int,
    FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID)
    ON DELETE CASCADE
);

🤔 Краткий ответ

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

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Что если покрыть код контроллера тестами?

💬 Спрашивают в 11% собеседований

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

🤔 Что такое тесты для контроллеров

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

1️⃣ Модульные тесты (Unit Tests):

➕ Проверяют отдельные методы контроллеров изолированно от других компонентов системы, используя заглушки или моки для зависимостей.

2️⃣ Интеграционные тесты (Integration Tests):

➕ Проверяют взаимодействие контроллера с другими компонентами системы, такими как сервисы, репозитории и базы данных.

🤔 Зачем нужно покрывать код контроллеров тестами

1️⃣ Проверка правильности кода:

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

2️⃣ Обнаружение ошибок:

➕ Автоматическое тестирование позволяет выявить ошибки на ранних стадиях разработки, что снижает затраты на их исправление.

3️⃣ Поддержка рефакторинга:

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

4️⃣ Документация:

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

5️⃣ Улучшение архитектуры:

➕ Написание тестов способствует созданию более модульного и тестируемого кода, что улучшает архитектуру приложения.

🤔 Как покрывать код контроллеров тестами

🤔 Модульные тесты

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

Пример модульного теста контроллера с использованием библиотеки xUnit и Moq:

using Moq;
using Xunit;
using MyWebApp.Controllers;
using MyWebApp.Services;
using Microsoft.AspNetCore.Mvc;

public class MyControllerTests
{
    [Fact]
    public void Get_ReturnsOkResult_WithListOfItems()
    {
        // Arrange
        var mockService = new Mock<IMyService>();
        mockService.Setup(service => service.GetItems()).Returns(new List<string> { "Item1", "Item2" });

        var controller = new MyController(mockService.Object);

        // Act
        var result = controller.Get();

        // Assert
        var okResult = Assert.IsType<OkObjectResult>(result);
        var items = Assert.IsType<List<string>>(okResult.Value);
        Assert.Equal(2, items.Count);
    }
}

🤔 Интеграционные тесты

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

Пример интеграционного теста с использованием xUnit и TestServer из Microsoft.AspNetCore.TestHost:

using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc.Testing;
using Xunit;

public class MyControllerIntegrationTests : IClassFixture<WebApplicationFactory<MyWebApp.Startup>>
{
    private readonly HttpClient _client;

    public MyControllerIntegrationTests(WebApplicationFactory<MyWebApp.Startup> factory)
    {
        _client = factory.CreateClient();
    }

    [Fact]
    public async Task Get_ReturnsOkResult_WithListOfItems()
    {
        // Act
        var response = await _client.GetAsync("/api/my");

        // Assert
        response.EnsureSuccessStatusCode();
        var responseString = await response.Content.ReadAsStringAsync();
        Assert.Contains("Item1", responseString);
    }
}

🤔 Краткий ответ

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

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Какой слой rest и swap с точки зрения трехслойной архитектуры?

💬 Спрашивают в 11% собеседований

В трехслойной архитектуре (трехуровневая архитектура), также известной как многоуровневая архитектура, приложения разделяются на три логических слоя:

1️⃣ Презентационный слой (Presentation Layer):

➕ Отвечает за взаимодействие с пользователем.

➕ Веб-интерфейсы, мобильные приложения, десктопные приложения.

➕ Примеры: HTML/CSS/JavaScript для веб-приложений, UI-компоненты в мобильных и десктопных приложениях.

2️⃣ Логический слой (Business Logic Layer):

➕ Содержит бизнес-логику и правила приложения.

➕ Обрабатывает данные, выполняет вычисления, применяет бизнес-правила.

➕ Примеры: классы и методы, реализующие бизнес-логику, сервисы, обработчики данных.

3️⃣ Слой данных (Data Access Layer):

➕ Отвечает за взаимодействие с источниками данных.

➕ Операции с базами данных, файловыми системами, внешними сервисами.

➕ Примеры: репозитории, Data Access Objects (DAO), API-клиенты для доступа к внешним системам.

🤔 REST и SWAP в контексте трехслойной архитектуры

🤔 REST

REST (Representational State Transfer):

➕ REST — это архитектурный стиль для разработки веб-сервисов. RESTful сервисы используют стандартные HTTP методы (GET, POST, PUT, DELETE и т.д.) для работы с ресурсами.

С точки зрения трехслойной архитектуры:

➕ Презентационный слой:

➕ Вызовы REST API могут происходить с клиентской стороны (например, AJAX запросы из веб-интерфейса) или через клиентские приложения.

➕ Пример: фронтенд веб-приложения, который взаимодействует с REST API.

➕ Логический слой:

➕ REST API реализует бизнес-логику и выступает посредником между презентационным слоем и слоем данных.

➕ Пример: контроллеры и сервисы, обрабатывающие REST запросы и выполняющие соответствующую бизнес-логику.

➕ Слой данных:

➕ REST API может взаимодействовать с базой данных или другими источниками данных для получения и сохранения информации.

➕ Пример: методы в API, которые выполняют запросы к базе данных через репозитории или DAO.

🤔 SWAP

SWAP (Simple Web API):

➕ SWAP — это гипотетический или менее распространенный термин, часто интерпретируемый как упрощенный API для веб-приложений.

С точки зрения трехслойной архитектуры:

➕ Презентационный слой:

➕ Клиентские приложения или пользовательские интерфейсы могут вызывать методы SWAP для получения или отправки данных.

➕ Пример: веб-страницы или мобильные приложения, обращающиеся к SWAP для выполнения операций.

➕ Логический слой:

➕ SWAP обрабатывает бизнес-логику аналогично REST API, предоставляя упрощенные конечные точки для взаимодействия с данными.

➕ Пример: сервисы, которые реализуют простые операции (CRUD) без сложной бизнес-логики.

➕ Слой данных:

➕ SWAP взаимодействует с базой данных или другими источниками данных для выполнения операций чтения/записи.

➕ Пример: методы SWAP, которые обращаются к базе данных через абстрактные уровни доступа к данным.

🤔 Заключение

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

🤔 Краткий ответ

➕ REST и SWAP чаще всего относятся к логическому слою в трехслойной архитектуре, так как они реализуют бизнес-логику и обеспечивают взаимодействие между презентационным слоем и слоем данных.

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Сравни паттерны Adapter и Decorator?

💬 Спрашивают в 11% собеседований

Паттерны Adapter и Decorator оба являются структурными паттернами, которые помогают управлять взаимодействием между объектами. Однако, они решают разные задачи и применяются в различных контекстах. Рассмотрим каждый из этих паттернов подробнее и сравним их.

🤔 Adapter (Адаптер)

Описание:

➕ Паттерн Adapter используется для приведения интерфейса одного класса к интерфейсу, ожидаемому клиентом. Он позволяет объектам с несовместимыми интерфейсами работать вместе.

Цель:

➕ Преобразование интерфейса класса в другой интерфейс, который ожидает клиент.

Применение:

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

➕ Когда необходимо интегрировать класс с внешней библиотекой, имеющей несовместимый интерфейс.

Пример:

// Существующий класс с несовместимым интерфейсом
public class LegacyPrinter
{
    public void PrintLegacy(string text)
    {
        Console.WriteLine("Legacy print: " + text);
    }
}

// Целевой интерфейс, который ожидает клиент
public interface IPrinter
{
    void Print(string text);
}

// Адаптер, который приводит интерфейс LegacyPrinter к интерфейсу IPrinter
public class PrinterAdapter : IPrinter
{
    private readonly LegacyPrinter _legacyPrinter;

    public PrinterAdapter(LegacyPrinter legacyPrinter)
    {
        _legacyPrinter = legacyPrinter;
    }

    public void Print(string text)
    {
        _legacyPrinter.PrintLegacy(text);
    }
}

// Использование адаптера
public class Client
{
    public void ClientCode(IPrinter printer)
    {
        printer.Print("Hello, World!");
    }
}

var legacyPrinter = new LegacyPrinter();
var adapter = new PrinterAdapter(legacyPrinter);
var client = new Client();
client.ClientCode(adapter);

🤔 Decorator (Декоратор)

Описание:

➕ Паттерн Decorator используется для динамического добавления новых функциональных возможностей объекту. Он предоставляет гибкую альтернативу наследованию для расширения функциональности.

Цель:

➕ Добавление новых обязанностей объекту динамически.

Пример:

// Базовый интерфейс
public interface INotifier
{
    void Send(string message);
}

// Конкретный компонент
public class EmailNotifier : INotifier
{
    public void Send(string message)
    {
        Console.WriteLine("Sending Email: " + message);
    }
}

// Базовый декоратор
public class NotifierDecorator : INotifier
{
    private readonly INotifier _wrappee;

    public NotifierDecorator(INotifier notifier)
    {
        _wrappee = notifier;
    }

    public virtual void Send(string message)
    {
        _wrappee.Send(message);
    }
}

// Конкретный декоратор
public class SMSNotifier : NotifierDecorator
{
    public SMSNotifier(INotifier notifier) : base(notifier) { }

    public override void Send(string message)
    {
        base.Send(message);
        Console.WriteLine("Sending SMS: " + message);
    }
}

// Использование декоратора
var emailNotifier = new EmailNotifier();
var smsNotifier = new SMSNotifier(emailNotifier);
smsNotifier.Send("Hello, World!");

🤔 Краткий ответ

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

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Что делает паттерн проектирования Factory?

💬 Спрашивают в 11% собеседований

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

🤔 Основные аспекты паттерна Factory

1️⃣ Абстрагирование процесса создания объектов:

➕ Паттерн Factory позволяет отделить логику создания объектов от логики их использования.

➕ Это помогает избежать жесткой привязки к конкретным классам и облегчает изменение или расширение типов создаваемых объектов.

2️⃣ Гибкость и расширяемость:

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

3️⃣ Снижение сложности кода:

➕ Фабрика централизует создание объектов, что помогает упростить код клиентов, делая его более читабельным и управляемым.

🤔 Виды паттерна Factory

1️⃣ Простая фабрика (Simple Factory):

➕ Не является отдельным паттерном, а скорее идиомой или шаблоном. Фабричный метод находится в одном классе, который создает объекты различных типов.

➕ Пример:

     public class SimpleFactory
     {
         public IProduct CreateProduct(string type)
         {
             if (type == "A")
                 return new ProductA();
             else if (type == "B")
                 return new ProductB();
             else
                 throw new ArgumentException("Unknown product type.");
         }
     }
     

2️⃣ Фабричный метод (Factory Method):

➕ Определяет интерфейс для создания объекта, но позволяет подклассам изменять тип создаваемого объекта.

➕ Пример:

     public abstract class Creator
     {
         public abstract IProduct FactoryMethod();
     }

     public class ConcreteCreatorA : Creator
     {
         public override IProduct FactoryMethod()
         {
             return new ProductA();
         }
     }

     public class ConcreteCreatorB : Creator
     {
         public override IProduct FactoryMethod()
         {
             return new ProductB();
         }
     }
     

🤔 Краткий ответ

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

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Как сейчас делается Singleton?

💬 Спрашивают в 11% собеседований

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

1️⃣ Ленивый Singleton (Lazy Initialization)

Ленивый Singleton инициализируется при первом обращении. Это обеспечивает отложенную инициализацию объекта и гарантирует потокобезопасность.

Пример:

public class Singleton
{
    private static readonly Lazy<Singleton> lazyInstance = new Lazy<Singleton>(() => new Singleton());

    public static Singleton Instance => lazyInstance.Value;

    private Singleton()
    {
        // Приватный конструктор
    }
}

➕ Lazy<T>: Использование класса Lazy<T> позволяет легко и безопасно реализовать отложенную инициализацию.

2️⃣ Потокобезопасный Singleton (Thread-safe)

Этот подход использует lock для обеспечения потокобезопасности при создании экземпляра.

Пример:

public class Singleton
{
    private static Singleton instance;
    private static readonly object lockObj = new object();

    private Singleton()
    {
        // Приватный конструктор
    }

    public static Singleton Instance
    {
        get
        {
            if (instance == null)
            {
                lock (lockObj)
                {
                    if (instance == null)
                    {
                        instance = new Singleton();
                    }
                }
            }
            return instance;
        }
    }
}

➕ Double-checked locking: Этот метод минимизирует накладные расходы, связанные с использованием lock, проверяя instance дважды.

3️⃣ Eager Initialization (Инициализация при загрузке)

Экземпляр Singleton создается при загрузке класса. Это гарантирует потокобезопасность за счет особенностей инициализации статических переменных в .NET.

Пример:

public class Singleton
{
    private static readonly Singleton instance = new Singleton();

    public static Singleton Instance => instance;

    private Singleton()
    {
        // Приватный конструктор
    }
}

➕ Простота: Этот метод прост и эффективен, но не поддерживает отложенную инициализацию.

4️⃣ Static Constructor (Статический конструктор)

Использование статического конструктора для инициализации Singleton.

Пример:

public class Singleton
{
    private static readonly Singleton instance;

    static Singleton()
    {
        instance = new Singleton();
    }

    public static Singleton Instance => instance;

    private Singleton()
    {
        // Приватный конструктор
    }
}

➕ Статический конструктор: Гарантирует инициализацию перед первым использованием любого члена класса.

5️⃣ Singleton с внедрением зависимостей (Dependency Injection)

В современных приложениях, особенно с использованием ASP.NET Core, Singleton часто регистрируется в контейнере внедрения зависимостей.

Пример:

public class SingletonService
{
    public void DoWork()
    {
        // Выполнение работы
    }
}

// Регистрация в контейнере служб
public void ConfigureServices(IServiceCollection services)
{
    services.AddSingleton<SingletonService>();
}

// Использование в контроллере
public class MyController : ControllerBase
{
    private readonly SingletonService _singletonService;

    public MyController(SingletonService singletonService)
    {
        _singletonService = singletonService;
    }

    public IActionResult Index()
    {
        _singletonService.DoWork();
        return Ok();
    }
}

🤔 Краткий ответ

В C# паттерн Singleton реализуется с использованием различных подходов: ленивой инициализации (с Lazy<T>), потокобезопасного двойного блокирования, инициализации при загрузке класса и статического конструктора. В современных приложениях также используется внедрение зависимостей (DI), особенно в ASP.NET Core, для обеспечения единственного экземпляра.

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Способы расширить поведение классов в C# на практике?

💬 Спрашивают в 11% собеседований

🤔 Способы расширения поведения классов в C#

1️⃣ Наследование: Создание подклассов, которые наследуют и переопределяют методы базового класса.

   public class BaseClass
   {
       public virtual void DoWork() { /* базовое поведение */ }
   }

   public class DerivedClass : BaseClass
   {
       public override void DoWork() { /* расширенное поведение */ }
   }
   

2️⃣ Интерфейсы: Определение интерфейсов и их реализация в классах.

   public interface IWork
   {
       void DoWork();
   }

   public class MyClass : IWork
   {
       public void DoWork() { /* реализация интерфейса */ }
   }
   

3️⃣ Декоратор: Оборачивание класса в другой класс для добавления поведения.

   public class BaseClass
   {
       public virtual void DoWork() { /* базовое поведение */ }
   }

   public class Decorator : BaseClass
   {
       private BaseClass _base;
       public Decorator(BaseClass baseClass) { _base = baseClass; }
       public override void DoWork()
       {
           _base.DoWork();
           // Добавленное поведение
       }
   }
   

4️⃣ Адаптер: Преобразование интерфейса одного класса в интерфейс другого.

   public interface ITarget
   {
       void Request();
   }

   public class Adaptee
   {
       public void SpecificRequest() { /* специальное поведение */ }
   }

   public class Adapter : ITarget
   {
       private Adaptee _adaptee = new Adaptee();
       public void Request() { _adaptee.SpecificRequest(); }
   }
   

5️⃣ Расширяющие методы: Добавление методов к существующим типам без изменения их кода.

   public static class Extensions
   {
       public static void NewMethod(this ExistingClass obj)
       {
           // Добавленное поведение
       }
   }
   

🤔 Краткий ответ

Поведение классов в C# можно расширить через наследование, интерфейсы, паттерн декоратор, адаптер и расширяющие методы.

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых