В чем суть оптимизации 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" заключается в минимизации издержек на копирование данных, проводя копирование только тогда, когда это действительно необходимо для изменения данных. Это улучшает производительность при работе с большими структурами данных, сохраняя при этом безопасность и простоту работы с типами значений.

👉 Можно посмотреть примеры как отвечают люди на этот вопрос, или перейти к списку 823 вопросов на IOS разработчика. Ставь 👍 если нравится контент

Что такое 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 помогает создавать более гибкие, устойчивые к изменениям и легкие в поддержке системы. Применение этих принципов способствует созданию кода, который легче понимать, расширять и поддерживать.

👉 Можно посмотреть примеры как отвечают люди на этот вопрос, или перейти к списку 823 вопросов на IOS разработчика. Ставь 👍 если нравится контент

В чем разница между "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" ссылки предполагают, что другой объект будет жить столько же или дольше, и поэтому они не являются опциональными и не обнуляются.

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

👉 Можно посмотреть примеры как отвечают люди на этот вопрос, или перейти к списку 823 вопросов на IOS разработчика. Ставь 👍 если нравится контент

Что такое ассоциированный тип (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.

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

👉 Можно посмотреть примеры как отвечают люди на этот вопрос, или перейти к списку 823 вопросов на IOS разработчика. Ставь 👍 если нравится контент

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