📌 Какие виды диспетчеризации существуют в свифт?

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

В Swift существует несколько видов диспетчеризации, которые определяют, как и когда вызываются методы или функции. Основные виды диспетчеризации включают статическую диспетчеризацию (static dispatch), диспетчеризацию по таблице виртуальных функций (vtable dispatch), диспетчеризацию по свидетелю (witness table dispatch) и динамическую диспетчеризацию (dynamic dispatch). Рассмотрим их подробнее:

1️⃣ Статическая диспетчеризация (Static Dispatch)
➕ Описание: Вызов функции или метода определяется на этапе компиляции. Используется для функций и методов, которые не переопределяются в подклассах или не являются динамическими.

➕ Использование: Для структур, перечислений и final классов.

➕ Пример:

     struct MyStruct {
         func printMessage() {
             print("Hello from MyStruct")
         }
     }

     let instance = MyStruct()
     instance.printMessage() // Вызов определяется на этапе компиляции
     

2️⃣ Диспетчеризация по таблице виртуальных функций (Vtable Dispatch)
➕ Описание: Используется для вызова методов класса, которые могут быть переопределены в подклассах. Виртуальная таблица (vtable) используется для определения, какой метод вызывать.

➕ Использование: Для классов и их подклассов.

➕ Пример:

     class BaseClass {
         func printMessage() {
             print("Hello from BaseClass")
         }
     }

     class SubClass: BaseClass {
         override func printMessage() {
             print("Hello from SubClass")
         }
     }

     let instance: BaseClass = SubClass()
     instance.printMessage() // Вызов определяется в runtime с использованием vtable
     

3️⃣ Диспетчеризация по свидетелю (Witness Table Dispatch)
➕ Описание: Используется для вызова методов протоколов, реализованных типами. Таблица свидетелей (witness table) используется для определения, какой метод вызывать.

➕ Использование: Для типов, соответствующих протоколам.

➕ Пример:

     protocol MyProtocol {
         func printMessage()
     }

     struct MyStruct: MyProtocol {
         func printMessage() {
             print("Hello from MyStruct")
         }
     }

     let instance: MyProtocol = MyStruct()
     instance.printMessage() // Вызов определяется в runtime с использованием witness table
     

4️⃣ Динамическая диспетчеризация (Dynamic Dispatch)
➕ Описание: Используется для вызова методов, отмеченных как dynamic или методов Objective-C. Метод определяется в runtime с использованием Objective-C runtime.

➕ Использование: Для методов, которые должны быть динамически разрешены в runtime, обычно для взаимодействия с Objective-C.

➕ Пример:

     import Foundation

     class MyClass: NSObject {
         @objc dynamic func printMessage() {
             print("Hello from MyClass")
         }
     }

     let instance = MyClass()
     instance.printMessage() // Вызов определяется в runtime с использованием Objective-C runtime
     

🤔 Заключение

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

В двух фразах: В Swift есть статическая и динамическая диспетчеризация, а также диспетчеризация через vtable и witness table. Они определяют, как и когда вызываются методы, обеспечивая гибкость и производительность.

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

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

📌 В чем суть оптимизации copy on write ?

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

Оптимизация "copy on write" (COW) представляет собой стратеги оптимизации управления памятью, применяемую к коллекциям и другим структурам данных, которые ведут себя как типы значений (value types), такие как структуры и перечисления. Эта стратегия позволяет избежать ненужного копирования объектов до тех пор, пока не произойдет попытка изменения.

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

Чтобы оптимизировать производительность, используется техника "copy on write". Суть её в том, что фактическое копирование происходит только в момент изменения данных. Если вы просто передаете данные или работаете с ними в режиме только для чтения, копирование не производится. Это значительно снижает нагрузку на память и процессор, особенно при работе с большими объемами данных.

🤔 Примером может служить работа с массивами:

var original = [1, 2, 3]
var copy = original // Здесь копирование не происходит, обе переменные ссылаются на один и тот же участок памяти

copy.append(4) // Только сейчас происходит фактическое копирование, так как мы модифицируем `copy`

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

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

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

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

📌 Что такое Solid ?

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

SOLID — это аббревиатура, обозначающая пять основных принципов объектно-ориентированного программирования и дизайна, которые помогают разработчикам создавать системы, легкие в поддержке и расширении. Эти принципы были сформулированы Робертом Мартином (Uncle Bob) и являются ключевыми в построении эффективных, масштабируемых и поддерживаемых программных систем. Вот они:

1️⃣ Single Responsibility Principle (Принцип единственной ответственности) - каждый класс должен иметь только одну причину для изменения. Этот принцип подчеркивает важность разделения обязанностей в программном обеспечении, чтобы каждый модуль или класс был ответственен за одну функциональность.

2️⃣ Open/Closed Principle (Принцип открытости/закрытости) - программные сущности (классы, модули, функции и т.д.) должны быть открыты для расширения, но закрыты для модификации. Это означает, что можно добавлять новую функциональность без изменения существующего кода.

3️⃣ Liskov Substitution Principle (Принцип подстановки Барбары Лисков) - объекты в программе должны быть заменяемы их наследниками без влияния на корректность программы. Этот принцип поддерживает концепцию полиморфизма и наследования, обеспечивая, чтобы подклассы могли служить заменой для их базовых классов.

4️⃣ Interface Segregation Principle (Принцип разделения интерфейса) - клиенты не должны быть вынуждены зависеть от интерфейсов, которые они не используют. Суть в том, чтобы разбивать большие интерфейсы на мелкие и специфичные, чтобы их реализация не заставляла классы имплементировать методы, которые они не будут использовать.

5️⃣ Dependency Inversion Principle (Принцип инверсии зависимостей) - модули высокого уровня не должны зависеть от модулей низкого уровня. Обе стороны должны зависеть от абстракций. Кроме того, абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций. Этот принцип направлен на снижение зависимостей между различными частями программы, что делает ее более модульной и упрощает тестирование.

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

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

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

📌 В чем разница между "Weak" и "Unowned"?

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

Когда работаешь с замыканиями или опциональными типами, часто встречаешься с понятиями "weak" и "unowned". Оба этих ключевых слова используются для предотвращения утечек памяти в случае циклических ссылок, но между ними есть важные различия.

1️⃣ Weak (слабая ссылка):

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

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

➕ Обычно используется для предотвращения циклических ссылок в случаях, когда два объекта (A и B) могут существовать независимо друг от друга, и один из них (скажем, B) может быть уничтожен первым.

class ExampleClass {
    var property: AnotherClass?
}

class AnotherClass {
    weak var backReference: ExampleClass?
}

2️⃣ Unowned (несильная ссылка):

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

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

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

class ExampleClass {
    var property: AnotherClass?
}

class AnotherClass {
    unowned var backReference: ExampleClass
}

Главное различие заключается в том, что "weak" ссылки всегда являются опциональными и автоматически становятся nil, когда объект удаляется, предотвращая висячие указатели. "Unowned" ссылки предполагают, что другой объект будет жить столько же или дольше, и поэтому они не являются опциональными и не обнуляются.

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

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

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

📌 Что такое ассоциированный тип (associated type) ?

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

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

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

🤔 Пример:

protocol Container {
    associatedtype Item // Определение ассоциированного типа
    
    mutating func append(_ item: Item)
    var count: Int { get }
    subscript(i: Int) -> Item { get }
}

struct IntStack: Container {
    // конкретная реализация ассоциированного типа Item как Int
    typealias Item = Int

    // реализация требований протокола
    var items = [Item]()
    mutating func append(_ item: Item) {
        items.append(item)
    }
    var count: Int {
        return items.count
    }
    subscript(i: Int) -> Item {
        return items[i]
    }
}

В этом примере, протокол Container определяет требования для контейнерных типов, включая ассоциированный тип Item. Когда структура IntStack принимает протокол Container, она указывает, что ассоциированный тип Item будет представлен как Int. Это позволяет протоколу Container быть адаптивным и работать с любыми типами, сохраняя при этом строгую типизацию и безопасность типов, характерные для Swift.

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

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

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

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

💬 Спрашивают в 27%

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

Порождающие паттерны
Эти паттерны связаны с процессами создания объектов, делая систему независимой от способа создания, компоновки и представления объектов.

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

➕ Фабричный метод (Factory Method): Определяет интерфейс для создания объекта, но оставляет подклассам решение о том, какой класс инстанцировать.

➕ Абстрактная фабрика (Abstract Factory): Предоставляет интерфейс для создания семейств взаимосвязанных или взаимозависимых объектов без указания их конкретных классов.

➕ Прототип (Prototype): Позволяет копировать существующие объекты без делания кода зависимым от их классов.

➕ Строитель (Builder): Позволяет создавать сложные объекты пошагово, используя один и тот же процесс строительства для получения разных представлений.

Структурные паттерны описывают, как объединять объекты и классы в более крупные структуры.

➕ Адаптер (Adapter): Позволяет объектам с несовместимыми интерфейсами работать вместе.

➕ Мост (Bridge): Разделяет абстракцию и реализацию так, чтобы они могли изменяться независимо.

➕ Композит (Composite): Комбинирует объекты в древовидные структуры для представления иерархий "часть-целое".

➕ Декоратор (Decorator): Динамически добавляет объектам новые обязанности без изменения их реализации.

➕ Фасад (Facade): Предоставляет простой интерфейс к сложной системе классов, библиотеке или фреймворку.

➕ Прокси (Proxy): Предоставляет заместителя или заполнитель для другого объекта для контроля доступа к нему.

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

➕ Наблюдатель (Observer): Создаёт механизм подписки, позволяющий одним объектам следить и реагировать на события, происходящие в других объектах.

➕ Стратегия (Strategy): Определяет семейство алгоритмов, инкапсулирует каждый из них и делает их взаимозаменяемыми.

➕ Состояние (State): Позволяет объекту изменять своё поведение в зависимости от своего состояния.

➕ Команда (Command): Превращает запросы в объекты, позволяя передавать их как аргументы при вызове методов, ставить их в очередь, логировать и т.д.

➕ Цепочка обязанностей (Chain of Responsibility): Позволяет передавать запросы последовательно по цепочке обработчиков. Каждый последующий обработчик решает, может ли он обработать запрос сам и следует ли передать запрос дальше по цепочке.

➕ Посредник (Mediator): Позволяет уменьшить взаимосвязь между классами, вынося межклассовые взаимодействия в класс-посредник.

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

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

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