в каком случае лучше использовать структуру а не класс swift
Интервью — 10 вопросов про Swift. Часть 1
Салют, хабровчане! Майские закончились, и мы продолжаем запускать новые курсы. Эта статья приурочена к старту курса «iOS-разработчик». Обучение начнется 28 мая, а до тех пор у вас есть возможность побольше узнать о языке Swift и его особенностях. Это первая статья из трех, где в формате интервью рассматриваются достоинства и особенности языка Swift, на котором мы учим создавать приложения под iOS на наших курсах.
Что такое Swift и чем он хорош?
Swift — это универсальный и мультипарадигмальный язык программирования, разработанный корпорацией Apple для разработки решений под iOS, macOS, watchOS, tvOS и даже Linux.
В чем разница между классом и структурой?
В Swift есть четыре основных различия между классом и структурой. Классы имеют некоторые возможности, которых нет у структур:
В каких случаях использовать класс, а в каких — структуру?
В качестве простой шпаргалки: структуры стоит использовать тогда, когда выполняется одно или несколько из следующих условий.
Как передавать переменные в качестве ссылок?
Переменную можно передавать в качестве ссылки с помощью параметра inout. Inout означает, что изменение локальной переменной также изменит передаваемые параметры.
Что такое модуль?
Чем отличаются уровни доступа в Swift?
В Swift есть пять различных уровней доступа для сущностей в коде:
Что такое отложенная инициализация?
Отложенная инициализация — техника задержки создания объекта или выполнения другого процесса до тех пор, пока этот процесс не станет необходимым. Задержку можно использовать только с классами и структурами. Однако стоит понимать, что свойство lazy не является безопасным, потому что не инициализируется автоматически.
Вам всегда нужно объявлять свойство lazy как переменную с использованием var. Свойства констант всегда должны иметь значение до завершения инициализации, поэтому они не могут быть отложенными.
Что такое кортеж?
Кортеж — это группа из нуля или более значений, представленных как одно значение. Они обычно используются для возврата нескольких значений из функции вызова. В Swift два вида кортежей.
Безымянный кортеж
В этом типе кортежа мы не указываем имен для элементов.
Что такое перечисления?
С помощью перечисления определяется общий тип для группы связанных значений и обеспечивается возможность безопасной работы с этими значениями в коде. В отличие от C и Objective-C, в Swift перечислениям при создании не присваиваются целочисленные значения по умолчанию.
Что такое связанные значения?
Связанные значения очень похожи на переменные, связанные с одним из случаев перечисления.
Определяем тип перечисления Barcode, который может принимать либо значение upc со связанным значением типа (Int, Int, Int, Int), либо значение qrCode со связанными значением типа String.
Иногда возможность хранить связанные значения других типов рядом со значениями case может быть полезна. Это позволяет хранить дополнительную пользовательскую информацию вместе со значением case и позволяет изменять эту информацию при каждом использовании этого case в коде.
Конец первой части.
Вторая часть.
Приглашаем всех желающих поучаствовать в бесплатном вебинаре, на котором мы расскажем, чему научит вас этот курс.
Структуры против Классов
С самого начала, когда я начинал заниматься программированием, вставал вопрос, что использовать для улучшения быстродействия: структуру или класс; какие массивы лучше использовать и как. По поводу структур, Apple приветствует их использование, объясняя это тем, что они лучше поддаются оптимизации, и вся суть языка Swift — это структуры. Но есть и те, кто с этим не согласен, ведь можно красиво упростить код, отнаследовав один класс от другого и работая с таким классом. Для ускорения работы с классами создавали разные модификаторы и объекты, которые оптимизировались специально под классы, и тут уже сложно сказать, что и в каком случае будет быстрее.
Для расстановки всех точек на “е” я написал несколько тестов, которые используют обычные подходы к обработке данных: передача в метод, копирование, работа с массивами и так далее. Громких выводов я решил не делать, каждый решит для себя сам, стоит ли верить тестам, сможет скачать проект и посмотреть, как он будет работать у вас, и попробовать оптимизировать работу того или иного теста. Возможно даже выйдут новые фишки, которые я не упомянул, или они настолько редко используются, что я просто не слышал о них.
P.S. Я начинал работу над статьёй на Xcode 10.3 и было думал попробовать сравнить его скорость с Xcode 11, но всё же статья не про сравнение двух приложений, а о скорости работы наших приложений. Я не сомневаюсь, что время работы функций уменьшится, и то, что было плохо оптимизировано, станет быстрее. В итоге я дождался новый Swift 5.1 и решил проверить гипотезы на практике. Приятного чтения.
Тест 1: Сравним массивы на структурах и классах
Предположим, у нас есть некий класс, и мы хотим положить объекты этого класса в массив, обычное действие над массивом — это пройтись по нему циклом.
В массиве при использовании в нём классов и попытке по нему пройтись увеличивается количество ссылок, после завершения число ссылок на объект будет уменьшаться.
Если мы пройдемся по структуре, то в момент вызова объекта по индексу создастся копия объекта, смотрящая на ту же область памяти, но помеченная immutable. Сложно сказать, что быстрее: увеличение числа ссылок на объект или создание ссылки на область в памяти с отсутствием возможности её изменить. Проверим это на практике:
Рис. 1: Сравнение получения переменной из массивов на основе структур и классов
Тест 2. Сравненим ContiguousArray vs Array
Что более интересно — сравнить производительность массива (Array) с ссылочным массивом (ContiguousArray), который нужен специально для работы c классами, хранимыми в массиве.
Проверим производительность для следующих случаев:
ContiguousArray, хранящий struct с value типом
ContiguousArray, хранящий struct с String
ContiguousArray, хранящий class с value типом
ContiguousArray, хранящий class с String
Array, хранящий struct с value типом
Array, хранящий struct с String
Array, хранящий class с value типом
Array, хранящий class с String
Так как результаты тестов (тесты: передача в функцию с отключенной оптимизацией inline, передача в функцию c включенной оптимизацией inline, удаление элементов, добавление элементов, последовательный доступ к элементу в цикле) будут включать большое количество проведенных тестов (для 8 массивов по 5 тестов), я приведу наиболее значимые результаты:
Оптимизацией циклов для массивов служит lazy инициализатор коллекций, который позволяет пройтись лишь один раз по всему массиву, даже в том случае, если используется несколько фильтров или мапов над элементами массива.
В использовании структур в качестве инструмента оптимизации присутствуют свои подводные камни, такие как использование типов, которые внутри имеют ссылочную природу: строки, словари, ссылочный массивы. Тогда, когда переменная, хранящая в себе ссылочный тип, поступает на вход у какой-либо функции, происходит создание дополнительной ссылки на каждый элемент, который является классом. У этого есть и другая сторона, о ней чуть дальше. Можно попробовать использовать класс-оболочку над переменной. Тогда количество ссылок при передаче в функции увеличится только у неё, а количество ссылок на значения внутри структуры останутся прежними. В целом хочется посмотреть, какое количество переменных ссылочного типа должно быть в структуре, чтобы её производительность снизилась ниже, чем производительность классов с теми же параметрами. В сети есть статья “Stop Using Structs!”, которая задает тот же вопрос и отвечает на него. Я скачал проект и решил разобраться, что где происходит, и в каких случаях мы получаем медленные структуры. Автор показывает низкую производительность структур по сравнению с классами, спорить с тем, что создание нового объекта намного медленное занятие, чем увеличение ссылки на объект, абсурдно (поэтому я убрал строку, где в цикле каждый раз создается новый объект). Но если мы не будем создавать ссылку на объект, а будем просто передавать его в функцию для работы с ним, то разницы в производительности будет очень несущественная. Каждый раз, когда мы ставим inline(never) у функции, наше приложение обязано выполнять её и не создавать кода в строку. Судя по тестам, Apple сделала таким образом, что объект, передаваемый в функцию немного модифицируется, для структур компилятор меняет мутабельность и делает доступ к не мутабельным свойствам объекта ленивыми. В классе происходит нечто подобное, но заодно увеличивает число ссылок на объект. И теперь у нас есть объект lazy, все его поля также lazy, и каждый раз, когда мы вызываем переменную объекта, он его инициализирует. В этом у структур нет равных: при вызове в функции двух переменных, у объекта структура лишь немного уступает классу в скорости; при вызове трёх и более, структура всегда будет быстрее.
Тест 3: Сравниваем производительность Структур и Классов хранящих большие классы
Также я немного изменил сам метод, который вызывался при добавлении еще одной переменной (таким образом в методе инициализировались три переменные, а не две, как в статье), и что бы не было переполнения Int, заменил операции над переменными на сумму и вычитание. Добавил более понятные метрики времени (на скриншоте это секунды, но нам это не так важно, важно понимание получившихся пропорций), удаление фреймворка Darwin (не использую в проектах, возможно зря, разницы в тестах до/после добавления фреймворка в моём тесте нет), включение максимальной оптимизации и билд на релизной сборке (кажется, так будет честнее), и вот результат:
Рис. 2: Производительность структур и классов из статьи “Stop Using Structs”
Разнице в результатах теста незначительны.
Тест 4: Функция, принимающая Generic, Protocol и функция без Generic
Если взять дженерик функцию и передать туда два значения, объединенных только возможностью сравнения этих значений (func min), тогда код из трёх строк превратится в код из восьми (так говорит Apple). Но так бывает не всегда, у Xcode есть способы оптимизации, в которых, если он при вызове функции видит, что в него передается две структурных значения, он автоматически генерирует функцию, принимающую две структуры, и уже не копирует значений.
Рис. 3: Типичная Generic функция
Я решил протестировать две функции: в первой обьявлен тип данных Generic, второй принимает просто Protocol. В новой версии Swift 5.1 Protocol даже немного быстрее, чем Generic (до Swift 5.1 протоколы были в 2 раза медленнее), хотя по версии Apple всё должно быть наоборот, а вот когда дело касается прохода по массиву, нам уже надо приводить тип, что замедляет Generic (но они всё равно молодцы, ведь побыстрее протоколов):
Рис. 4: Сравнение Generic и Protocol принимающей функции.
Тест 5: Сравним вызов родительского метода и родного, а заодно проверим final класс на такой вызов
Что меня так же всегда интересовало, насколько медленно работают классы с большим число родителей, насколько класс быстро вызывает свои функции и функции родителя. В случаях, когда мы пытаемся вызвать метод, который принимает класс, вступает в игру динамическая диспетчеризация. Что это такое? Каждый раз, когда внутри нашей функции вызывается метод или переменная, генерируется сообщение, запрашивая у объекта эту переменную или метод. Объект, получая такой запрос, начинает поиск метода в таблице диспетчеризации своего класса, и если был вызван override метода или переменной, забирает её и возвращает, либо рекурсивно доходит до базового класса.
Рис. 5: Вызовы методов классов, для тестирования диспетчеризация
Из теста выше можно сделать несколько выводов: чем больше у класса родительских классов, тем медленнее он будет работать, и что разница в скорости работы настолько мала, что ей можно смело пренебрегать, скорее всего оптимизации кода сделает так, что разницы в скорости не будет. В данном примере преимущества у final модификатора класса нет, наоборот, работа класса даже медленнее, возможно это связано с тем, что действительно быстрой функцией она так и не становится.
Тест 6: Вызов переменной с модификатором final против обычной переменной класса
Тоже очень интересные результаты с присвоением модификатора final для переменной, его можно использовать, когда точно знаешь, что переменная не будет переписана нигде в наследниках класса. Попробуем поставить модификатор final к переменной. Если бы мы в нашем тесте создали лишь одну переменную и вызывали у неё свойство, тогда бы оно инициализировалось один раз (результат снизу). Если мы по-честному будем создавать каждый раз новый объект и запрашивать его переменную, скорость работы заметно замедлится (результат вверху):
Рис. 6: Вызов final переменной
Очевидно, что на пользу переменной модификатор не пошел, и она всегда медленнее своего конкурента.
Тест 7: Проблема полиморфизма и протоколов для структур. Или производительность Existential container
Проблема: если взять протокол, поддерживающий определенный метод, и несколько структур, наследуемых от этого протокола, то что будет думать наш компилятор, когда мы поместим структуры с разными объёмами хранимых значений в один массив, объединенный изначальным протоколом?
Для решения проблемы вызова метода, предопределенного в наследниках, используется механизм Protocol Witness Table. Он создает структуры оболочки, которые ссылаются на необходимые методы.
Для решения проблемы хранения данных используется Existential container. Он хранит в себе 5 ячеек информации, каждая по 8 байт. В первых трёх выделяется место под хранимые данные в структуре (если они не влезают, то он создает ссылку на кучу, в которой хранятся данные), в четвертой хранится информация о типах данных, которые используются в структуре, и говорит нам о способе управления этими данными, на пятой хранятся ссылки на методы объекта.
Рис 7. Сравнение производительности массива, который создает ссылку на объект и который его содержит
Между первым и вторым результатом число переменных увеличилось втрое. В теории, они должны помещаться в контейнер, они хранятся в этом контейнере, и разница в скорости обусловлена объемом структуры. Что интересно, если вы уменьшите число переменных во второй структуре, то время работы не изменится, то есть контейнер в самом деле хранит 3 или 2 переменные, но по-видимому, для одной переменной существуют особые условия, которые существенно повышают скорость. Вторая структура идеально вписывается в контейнер и отличается по объем от третьей в два раза, что даёт сильную деградацию по времени выполнения, в сравнении с остальными структурами.
Немного теории для оптимизации ваших проектов
На производительность структур могут влиять следующие факторы:
Чем плохи и опасны классы по сравнению со структурами
Мы не всегда управляем копированием наших объектов, а если мы это делаем, мы можем получить слишком много копий, которыми сложно будет управлять (насоздавали объектов в проекте, которые отвечают за формирование вьюшки, например).
Они не такие быстрые как структуры.
Если у нас есть ссылка на объект, и мы пытаемся управлять нашим приложением в многопоточном стиле, мы можем получить Race Condition в случае, когда наш объект используется из двух разных мест (а это не так сложно, ведь собранный с Xcode проект всегда чуть медленнее, чем Store версия).
Если мы пытаемся избежать Race Condition, мы тратим много ресурсов на Lock’и наших данных, что начинает подъедать ресурсы и тратить время вместо быстрой обработки и мы получаем еще более медленные объекты, чем те же самые, построенные на структурах.
Если мы проделываем все упомянутые выше действия над нашими объектами (ссылками), то велика вероятность возникновения непредвиденных deadlock’s.
Сложность кода из-за этого возрастает.
Больше кода = больше багов, всегда!
Выводы
Я подумал, что выводы в этой статье просто необходимы, потому что читать статью из раза в раз не хочется, и сводный перечень пунктов просто необходим. Подводя черту под тестами, хочется выделить следующее:
В отличие от других языков программирования, Swift не требует создания отдельных файлов интерфейса и реализации для пользовательских структур и классов. В Swift вы определяете структуру или класс в одном файле, и внешний интерфейс для этого класса или структуры автоматически становится доступным для использования другим кодом.
Сравнение структур и классов
Структуры и классы в Swift имеют много общего. Оба могут:
У классов есть дополнительные возможности, которых нет у структур:
Синтаксис определения
Структуры и классы имеют похожий синтаксис определения. Вы вводите структуры с struct ключевым словом и классы с class ключевым словом. Оба помещают все свое определение в пару фигурных скобок:
Вот пример определения структуры и определения класса:
Структура и классовые экземпляры
Определение Resolution структуры и определение VideoMode класса описывают только то, как Resolution или VideoMode будет выглядеть. Сами они не описывают конкретное разрешение или режим видео. Для этого вам нужно создать экземпляр структуры или класса.
Синтаксис для создания экземпляров очень похож для структур и классов:
Доступ к свойствам
Вы можете углубиться в подвойства, такие как width свойство в resolution свойстве VideoMode :
Вы также можете использовать точечный синтаксис для присвоения нового значения свойству переменной:
Поэлементные инициализаторы для типов структуры
Структуры и перечисления являются типами значений
Все структуры и перечисления являются типами значений в Swift. Это означает, что любые создаваемые вами структуры и экземпляры перечисления, а также любые типы значений, которые они имеют в качестве свойств, всегда копируются при передаче в ваш код.
Коллекции, определенные стандартной библиотекой, такие как массивы, словари и строки, используют оптимизацию для снижения производительности копирования. Вместо немедленного создания копии эти коллекции совместно используют память, в которой хранятся элементы между исходным экземпляром и любыми копиями. Если одна из копий коллекции изменена, элементы копируются непосредственно перед изменением. Поведение, которое вы видите в своем коде, всегда такое, как если бы копия произошла немедленно.
Рассмотрим этот пример, который использует Resolution структуру из предыдущего примера:
В этом примере объявляется вызываемая константа hd и устанавливается ее Resolution экземпляр, инициализированный с шириной и высотой видео Full HD (ширина 1920 пикселей и высота 1080 пикселей).
Затем width свойство cinema изменено на ширину чуть более широкого стандарта 2К, используемого для проецирования цифрового кино (2048 пикселей в ширину и 1080 пикселей в высоту):
Проверка width свойства cinema показывает, что оно действительно изменилось на 2048 :
Однако width свойство исходного hd экземпляра все еще имеет старое значение 1920 :
То же самое относится и к перечислениям:
Классы являются ссылочными типами
Вот пример, используя VideoMode класс, определенный выше:
Потому что классы являются ссылочными типами, tenEighty и alsoTenEighty фактически оба ссылаются на один и тот же VideoMode экземпляр. По сути, это просто два разных имени для одного и того же экземпляра.
Проверка frameRate свойства tenEighty показывает, что он правильно сообщает о новой частоте кадров 30.0 из базового VideoMode экземпляра:
Идентификационные операторы
Поскольку классы являются ссылочными типами, несколько констант и переменных могут ссылаться на один и тот же экземпляр класса за кулисами. (То же самое не относится к структурам и перечислениям, потому что они всегда копируются, когда они присваиваются константе или переменной или передаются функции.)
Иногда полезно выяснить, относятся ли две константы или переменные к одному и тому же экземпляру класса. Чтобы включить это, Swift предоставляет два идентификатора операторов:
Используйте эти операторы, чтобы проверить, относятся ли две константы или переменные к одному и тому же экземпляру:
Указатели
Если у вас есть опыт работы с C, C ++ или Objective-C, вы можете знать, что эти языки используют указатели для обращения к адресам в памяти. Константа или переменная Swift, которая ссылается на экземпляр некоторого ссылочного типа, похожа на указатель в C, но не является прямым указателем на адрес в памяти и не требует, чтобы вы записывали звездочку ( * ), чтобы указать, что Вы создаете ссылку. Вместо этого эти ссылки определяются как любая другая константа или переменная в Swift.
структура против класса на языке swift
из книги Apple «Одно из важнейших различий между структурами и классами заключается в том, что структуры всегда копируются, когда они передаются в коде, но классы передаются по ссылке.»
может ли кто-нибудь дать мне понять, что это значит, для меня класс и структура, похоже, одинаковы.
12 ответов:
С struct мы видим, что значения копируются и каждая переменная сохраняет свой собственный набор ценностей. Когда мы устанавливаем имя в Sue на Bob struct in aStruct не изменяется.
Итак, для представления комплекса с состоянием сущность, class это круто. Но для значений, которые являются просто измерением или битами связанных данных, a struct больше смысла, так что вы можете легко скопировать их и работать с ними или изменить значения, не опасаясь побочных эффектов.
как класс, так и структура могут делать:
только класс может сделать:
struct типы значений. Это означает, что если вы копируете экземпляр структуры в другую переменную, он просто копируется в переменную.
классы являются ссылочными типами. Это означает, что если вы назначите экземпляр класса переменной, он будет содержать только ссылка к примеру и не скопировать.
основные различия между структурами и классами:
Если вы посмотрите дальше в руководстве apple, вы увидите этот раздел: «Структуры и перечисления являются типами значений»
в этом разделе вы увидите это:
» пусть hd = разрешение (ширина: 1920, высота: 1080) var cinema = hd в этом примере объявляется константа с именем hd и устанавливается она к примеру разрешение инициализации с ширины и высоты полных HD видео (1920 пикселей в ширину и 1080 пикселей в высоту).
Это затем объявляет переменную с именем cinema и устанавливает ее в текущее значение стоимость HD-качестве. Поскольку разрешение-это структура, копия существующей экземпляр сделан,и эта новая копия назначена кино. Даже если hd и кино теперь имеют такую же ширину и высоту, они 2 совершенно разные экземпляры за кулисами.
затем, свойство ширины кино изменено для того чтобы быть шириной слегка более широкий стандарт 2K, используемый для цифровой кинопроекции (2048 пикселы ширину и 1080 пикселей в высоту):
кино.ширина = 2048 проверка ширины собственность киносеансы что он действительно изменился, чтобы быть 2048:
println («кино сейчас (кино.ширина) пикселей в ширину») // печатает » кино теперь 2048 пикселов широко однако, свойство ширины исходный экземпляр hd по-прежнему имеет старое значение 1920:
println («hd все еще (hd.ширина) пиксели широко») / / печатает » hd еще 1920 пикселей широкий»
когда кино было дано текущее значение hd, значения, сохраненные в hd были скопированы в новый экземпляр кино. Конечный результат-два совершенно разные экземпляры, которые просто случайно содержат одно и то же числовое значение. Поскольку они являются отдельными экземплярами, установка ширины кино до 2048 не влияет на ширину, сохраненную в hd.»
Отрывок Из: Apple Inc. «Язык Программирования Swift.»iBooks. https://itun.es/us/jEUH0.l
Это самая большая разница между структурами и классами. Структуры копируются, и на них ссылаются классы.
выше ответы правильные я надеюсь, что мой ответ поможет кому-то, кто не понимает выше ответов.
Ну в Swift есть два типа объектов
основное различие между ними
например здесь код для понимания что ж.
Это было основное различие, но у нас есть и суб различия.
класс
Struct
этот вопрос, похоже, дублируется, но независимо от этого, следующее ответит на большую часть варианта использования:
одним из самых важных различий между структурами и классами является то, что структуры являются типами значений и всегда копируются, когда они передаются в вашем коде, а классы являются ссылочным типом и передаются по ссылке.
кроме того, классы наследование позволяет одному классу наследовать характеристики о другом.
свойства структуры хранятся в стеке, а экземпляры классов хранятся на куче следовательно, иногда стек значительно быстрее, чем класс.
Struct автоматически получает инициализатор по умолчанию, тогда как в классе мы нужно инициализировать.
структура является потокобезопасной или одноэлементной в любой момент времени.
, а также, Чтобы суммировать разницу между структурами и классы, необходимо понимать разницу между значениями и ссылочными типами.
name используется для доступа к этим блокам данных. Этот механизм позволяет совместно использовать объекты в куче путем копирования значения их ссылок (указателей). Это не относится к базовым типам данных, таким как целые числа, и это связано с тем, что память, необходимая для создания ссылки, почти такая же, как и объект (в этом случае целочисленное значение.) Таким образом, они будут передаваться как значения, а не как ссылка в случае больших объектов.
Swift использует struct для повышения производительности даже со строковыми и массивными объектами.
чтобы понять разницу между структурами и классами, нам нужно знать основное различие между значениями и ссылочными типами. Структуры-это типы значений, и это означает, что каждое изменение в них просто изменит это значение, классы-ссылочные типы, и каждое изменение в ссылочном типе изменит значение, выделенное в этом месте памяти или ссылки. Например:
давайте начнем С класса, этот класс соответствует Equatable только для того, чтобы иметь возможность сравнивать экземпляры, мы создаем экземпляр с именем pointClassInstanceA и другие называют pointClassInstanceB мы присваиваем класс A классу B, теперь утверждение говорит, что они одинаковы.
хорошо, что здесь произошло почему, если мы просто изменили значение x pointsClassInstanceB он также изменил значение x pointClassInstanceA? ну, это показывает, как работают ссылочные типы, когда мы назначаем экземпляр A, как значение экземпляра B, а затем мы изменяем X одного из них, он изменит оба X, потому что они разделяют та же ссылка и то, что изменилось, было значением этой ссылки.
давайте сделаем то же самое, но с структуры
мы имеем в основном ту же структуру, что и наш класс, но теперь вы можете видеть, что при печати значения x pointStructInstanceA в этом случае оно не изменилось, и это связано с тем, что типы значений работают по-разному, и каждое изменение в одном из их экземпляров будет «независимым» и не повлияет на другое.
Swift предлагает использовать больше значения типы и вы можете сказать, что их библиотеки основаны на структурах, чтобы избежать проблем, которые приносят ссылочные типы, например, непреднамеренно изменить значение и т. д. Структуры-это способ идти на Swift. Надеюсь, это поможет.
вот пример, который точно показывает разницу между struct и class.
скриншот написанного кода на игровой площадке