Подклассы против протоколов

Давайте начнем с подхода Class :

 class LoginCredentials { var id : String init(userID:String) { self.id = userID } } 

у нас будет следующее:

 class FacebookLoginCredentials : LoginCredentials { var token : String init(userID:String,userToken:String) { self.token = userToken super.init(userID: userID) }} 

А также

 class TwitterLoginCredentials : LoginCredentials { var token : String var secret : String init(userID:String,userToken:String,secret : String) { self.token = userToken self.secret = secret super.init(userID: userID) } } 

Второй подход – это Protocol Oriented если я не ошибаюсь

 protocol LoginCredentials { var id : String { get } } 

то у нас будет:

 struct FacebookLoginCredentials : LoginCredentials { var id: String var token : String init(userID:String,userToken:String) { self.id = userID self.token = userToken } } 

А также

 struct TwitterLoginProfile : LoginCredentials { var id: String var token : String var secret : String init(userID:String,userToken:String,secret : String) { self.token = userToken self.secret = secret self.id = userID } } 

Мне просто нужно знать, какой из них более Свифт?

3 Solutions collect form web for “Подклассы против протоколов”

В конечном счете, ни один из этих подходов не является «более быстрым». В Swift вы иногда захотите использовать наследование и другие времена, когда вы захотите использовать протоколы. Реальная точка решения для этих двух подходов:

Вам нужна семантика типа значения (структуры и протоколы) или вам нужна семантика ссылочного типа (классы и протоколы). Обычно я использую семантику типа значения по умолчанию, потому что они более безопасны, но есть определенные обстоятельства, когда важна семантика ссылочного типа. Вы можете узнать больше об этом здесь: Почему выбрать «Создать над классом» .

Либо или приемлемо быстро.

Вот как вы хотите отличить их от двух.

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

Ballplayers must know what a ball is, so any person that wants to be a Ballplayer must know what a ball is.

У вас есть набор правил, которым вы хотите, чтобы определенные объекты следовали, сделать протокол.

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

Dad can throw a ball at 100MPH Junior can throw a ball at 100MPH and throw a curve ball.

Это будет сделано с классом, а не с протоколом

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

В качестве общего руководства рассмотрите вопрос о создании структуры при применении одного или нескольких из этих условий:

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

  • Размер геометрической формы, возможно, инкапсулирует свойство ширины и свойство высоты, оба типа Double.
  • Способ ссылаться на диапазоны внутри серии, возможно, инкапсулируя свойство start и свойство length, как типа Int.
  • Точка в трехмерной системе координат, возможно, инкапсулирующая свойства x, y и z, каждый из которых является двойным.

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

Зачем выбирать структуру над классом?

  • Свойство `_statusBarTintColorLockingControllers` в` UIApplication`, сохраняющее ViewController в памяти
  • Что нужно назвать идиоматическим кодом Swift, эквивалентным pythonic?
  • Разрешение Xcode Firebase Crash Reporting отклонено
  • Быстрое создание IBOulet как сильного
  • Swift: изменение размера AVPlayerLayer для соответствия границам его родительского контейнера
  • Какова цель DictionaryIndex в Swift?
  • Swift: «Должен вызывать назначенный инициализатор суперкласса», даже если код делает это
  • Как изменить ярлык «Отмена» от модального сегмента в Apple Watch
  • UITests: Как найти UIBarButtonItem с помощью accessibilityIdentifier с предикатом?
  • График отладочной памяти Xcode, показывающий выпущенный объект
  • Использование OpenCV в Swift iOS
  • Interesting Posts

    Как сделать снимок при событии увеличения громкости при использовании UIImagePickerController с пользовательскими элементами управления камерой?

    Повторное использование метода дает мне ошибку (IOS)

    iOS: ориентация устройства при нагрузке

    Можете ли вы установить вставки прокрутки для контейнерных контроллеров?

    Swift 3 добавить пользовательскую границу к одному из краев UIView

    Таблица заполнения с ответом API Swift

    Приложение сбой при получении всех кадров из видео с помощью AVAssetImageGenerator для длинных видеороликов

    Как заменить устаревший AudioUnitSampleType на iOS (Audio Units)?

    Пользовательская панель iOS

    Динамическая высота TableView в виде прокрутки

    Ошибка проверки: пакет содержит запрещенные вложенные пакеты

    Как получить Image.xcassets под контролем источника?

    Передача параметров в пользовательский класс при инициализации

    didSelectRowAtIndex не вызывается для WKInterfaceTable

    Добавление UIView в UITableViewCell через cell.contentView

    PhoneC: Разработка iOS проста с помощью XCode, Swift3, UITableView, cocatouch, давайте создадим приложения для iPhone, iPad и Macbook.