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

Давайте начнем с подхода 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 } } 

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

  • ярлык для раскрытия раскрывающегося метода в xcode
  • OSX Keychain Access - генерирует CSR из существующего Private Key для APNS (Apple Push Notification Service)
  • Каков правильный формат для сертификата Java APNS?
  • Хотите перечислить макросы Xcode и символы препроцессора для iOS (и Mac)
  • Не удается инициализировать структуру со значением по умолчанию
  • Неявные анимации свойств не работают с CAReplicatorLayer?
  • Функции расширения префикса
  • CoreAudio: Полный список «доступных для прослушивания» свойств?
  • 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, каждый из которых является двойным.

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

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

    Interesting Posts

    В чем разница между 5 способами настройки Магической записи?

    Добавить наложение поверх сканера ZBar

    Как открыть внешнюю ссылку в Safari, а не в UIWebView приложения?

    Воспроизведение зашифрованных видео с помощью AVPlayer в iOS

    Как удалить двуличие из массива словарей в IOS?

    Как импортировать собственные классы из собственного проекта в игровую площадку

    UIScrollView загадочно меняет размер кадра и содержимого

    Поймать UIViewAlertForUnsatisfiableConstraints в производстве

    Скопировать png-ошибку с кодом выхода 5

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

    Маска CGImage не работает на дисплеях Wide Color Gamut

    используя протокол Objective-C в Swift

    UICollectionView invalidateLayout не запускает sizeForItem при изменении ориентации экрана

    Как реализовать покупку In-App с динамической ценой без использования SDK сторонних разработчиков в IOS?

    UIViewController внутри корневого ViewController не вращается

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