Pourquoi Choisir Struct Plus De Classe?

Selon le très populaire de la WWDC 2015 parler Protocole de la Programmation Orientée dans Swift (vidéo, transcription), Swift fournit un certain nombre de caractéristiques qui en font des structures de mieux que de classes dans de nombreuses circonstances.

Les structures sont préférables si elles sont relativement petites et copiables parce que la copie est plus sûr que d'avoir de multiples références à la même instance, comme il arrive avec les classes. Ceci est particulièrement important lors du passage autour d'une variable à un grand nombre de classes et/ou dans un environnement multithread. Si vous pouvez toujours envoyer une copie de votre variable à d'autres endroits, vous n'aurez jamais à vous soucier de l'autre endroit en changeant la valeur de votre variable au-dessous de vous.

Avec les Structures, il y a beaucoup moins besoin de s'inquiéter à propos des fuites de mémoire ou plusieurs threads de course à consulter/modifier une seule instance d'une variable. (Pour les plus techniques d'esprit, l'exception à cela est lors de la capture d'une structure à l'intérieur d'une fermeture parce que c'est en fait la capture d'une référence à l'instance, sauf si vous explicitement de marquer pour être copié).

Classes peuvent également devenir énorme parce qu'une classe ne peut hériter que d'une seule super-classe. Ce qui nous encourage à créer d'énormes super-classes qui englobe de nombreuses différentes capacités qui ne sont que faiblement liées. En utilisant des protocoles, en particulier avec les extensions de protocole où vous pouvez fournir des implémentations de protocoles, permet d'éliminer la nécessité pour les classes à réaliser ce genre de comportement.

Le discours énonce ces scénarios où les classes sont privilégiées:

• La copie ou la comparaison des cas n'a pas de sens (par exemple, Fenêtre)
• Instance durée de vie est liée à des effets externes (par exemple, TemporaryFile)
• Les Instances sont des "puits de carbone"--écriture seule conduits à l'extérieure de l'état (e.g.CGContext)

Il implique que les structures devrait être la valeur par défaut et les classes devrait être une solution de repli.

D'autre part, Le Langage De Programmation Swift la documentation est un peu contradictoire:

Instances de Structure sont toujours passés par valeur, et de la classe
les instances sont toujours passés par référence. Cela signifie qu'ils sont
adapté à différents types de tâches. Que vous considérez que les données
les constructions et les fonctionnalités dont vous avez besoin pour un projet, décider
si chaque donnée de construire devrait être définie comme une classe ou une
structure.

En règle générale, envisager la création d'une structure lorsqu'un ou plusieurs
ces conditions s'appliquent:

• La structure, le premier objectif est d'encapsuler un peu de données relativement simples valeurs.
• Il est raisonnable de s'attendre à ce que la encapsulé valeurs seront copiés plutôt que de référence quand vous céder ou transmettre autour d'un
  instance de cette structure.
• Toutes les propriétés stockées par la structure sont eux-mêmes des types de valeur, ce qui devrait aussi être copié plutôt que référencés.
• La structure n'a pas besoin d'hériter de biens ou de comportement à partir d'un autre type existant.

Des exemples de bons candidats pour les structures comprennent:

• De la taille d'une forme géométrique, peut-être de l'encapsulation d'une propriété de largeur et d'une hauteur de propriété, à la fois de type Double.
• Un moyen de faire référence à des plages à l'intérieur d'une série, peut-être de l'encapsulation d'un départ à la propriété et d'une longueur de propriété, à la fois de type Int.
• Un point dans un système de coordonnées 3D, peut-être de l'encapsulation de x, y et z, chacune de type Double.

Dans tous les autres cas, de définir une classe, et de créer des instances de cette classe
pour être gérés et passé par référence. Dans la pratique, cela signifie que
la plupart des données constructions doivent être des classes et non des structures.

Ici, c'est de prétendre que nous devrions valeur par défaut à l'aide de classes et d'utiliser les structures que dans des circonstances particulières. En fin de compte, vous avez besoin de comprendre le monde réel implication des types de valeur contre les types référence, puis vous pouvez prendre une décision éclairée sur l'utilisation de structures ou classes. Aussi, gardez à l'esprit que ces concepts sont toujours en évolution et La Swift Langage de Programmation de la documentation a été écrite avant le Protocole de la Programmation Orientée conférence a été donnée.

OriginalL'auteur drewag

Similitudes entre les structures et les classes.

J'ai créé gist pour cela avec des exemples simples.
https://github.com/objc-swift/swift-classes-vs-structures

Et les différences

1. De l'héritage.

structures ne peuvent pas hériter de swift. Si vous voulez

class Vehicle{
}
class Car : Vehicle{
}

Aller pour une classe.

2. Passer Par

Swift structures passage par valeur et des instances de classe passage par référence.

Différences Contextuelles

Struct constantes et les variables

Exemple (Utilisé lors de la WWDC 2014)

struct Point{
var x = 0.0;
var y = 0.0;
} 

Définit une structure appelée Point.

var point = Point(x:0.0,y:2.0)

Maintenant, si j'essaie de modifier le x. Ses une expression valide.

point.x = 5

Mais si je définis un point en tant que constante.

let point = Point(x:0.0,y:2.0)
point.x = 5 //This will give compile time error.

Dans ce cas tout le point est immuable constante.

Si j'ai utilisé une classe Point au lieu de cela est une expression valide. Parce que dans une classe immuable constante, c'est la référence à la classe elle-même pas ses variables d'instance (à Moins que ces variables définies comme constantes)

OriginalL'auteur MadNik

En supposant que nous savons Struct est un type de valeur et Classe est un type de référence.

_{Si vous ne savez pas quel type de valeur et un type de référence sont ensuite voir Quelle est la différence entre le passage par référence vs passage par valeur?}

Basé sur mikeash post:

... Regardons quelques extrême, les exemples les plus évidents de la première. Les entiers sont
évidemment copiable. Ils doivent être des types de valeur. Les sockets réseau ne peut pas
être raisonnablement copié. Ils doivent être de types de référence. Points, comme dans x, y
paires, sont copiable. Ils doivent être des types de valeur. Un contrôleur de
représente un disque ne peut pas être raisonnablement copié. Qui devrait être une référence
type.

Certains types peuvent être copiés, mais il ne peut pas être quelque chose que vous voulez
se produisent tout le temps. Ceci suggère qu'ils devraient être de référence
les types. Par exemple, un bouton sur l'écran peut théoriquement être copié.
La copie ne sera pas tout à fait identique à l'original. Un clic sur l'
la copie ne sera pas activer l'original. La copie ne sera pas occuper le même
emplacement sur l'écran. Si vous passez sur le bouton autour de ou de le mettre dans un
nouvelle variable, vous voudrez probablement consulter le bouton d'origine, et
vous ne voulez faire une copie quand il est explicitement demandé. Que
signifie que votre type de bouton doit être d'un type référence.

Vue et de fenêtre, les contrôleurs sont un exemple similaire. Ils pourraient être
copiable, en théorie, mais elle n'est presque jamais ce que vous voulez le faire.
Ils doivent être de types de référence.

Que sur les types de modèle? Vous pourriez avoir un type d'Utilisateur représentant un utilisateur
sur votre système, ou d'un type de Crime qui représente une mesure prise par un
De l'utilisateur. Ce sont de jolies copiable, de sorte qu'ils devraient probablement être la valeur
les types. Cependant, vous voulez probablement des mises à jour à l'Utilisateur d'un Crime fait dans
un endroit dans votre programme de façon à être visible pour les autres parties du programme.
Ceci suggère que les Utilisateurs doivent être gérés par une sorte de l'utilisateur
contrôleur qui serait une référence de type. e.g

struct User {}
class UserController {
var users: [User]
func add(user: User) { ... }
func remove(userNamed: String) { ... }
func ...
}

Collections sont un cas intéressant. Ces inclure des choses comme des tableaux
et les dictionnaires, ainsi que des chaînes de caractères. Sont-ils copiable? Évidemment. Est
la copie de quelque chose que vous voulez arriver facilement et souvent? C'est moins
clair.

La plupart des langues dites "non" à ce et faire leurs collections de référence
les types. C'est vrai qu'en Objective-C et Java et Python et JavaScript
et presque toutes les autres langues que je connais. (Une exception majeure
est le C++ avec STL types de collection, mais le C++ est le fou furieux de la
mondial de la langue qui fait tout, étrangement.)

Swift a dit "oui", ce qui signifie que des types comme Matrice et Dictionnaire et
Chaîne sont des structures plutôt que de classes. Elles sont copiées lors de l'attribution,
et sur les passant en paramètres. C'est un choix judicieux
tant que la copie n'est pas cher, qui Swift essaie très dur pour
accomplir.
...

En outre, n'utilisez pas de classe lorsque vous devez remplacer chaque instance d'une fonction ie eux de ne pas avoir tout partagé fonctionnalité.

Alors au lieu d'avoir plusieurs sous-classes d'une classe. L'utilisation de plusieurs structures qui sont conformes à un protocole.

OriginalL'auteur Honey

Structure est beaucoup plus rapide que de Classe. Aussi, si vous avez besoin d'héritage, alors vous devez utiliser la Classe. Point le plus important est que la Classe est le type de référence alors que la Structure est de type valeur. par exemple,

class Flight {
var id:Int?
var description:String?
var destination:String?
var airlines:String?
init(){
id = 100
description = "first ever flight of Virgin Airlines"
destination = "london"
airlines = "Virgin Airlines"
} 
}
struct Flight2 {
var id:Int
var description:String
var destination:String
var airlines:String  
}

maintenant permet de créer une instance à la fois.

var flightA = Flight()
var flightB = Flight2.init(id: 100, description:"first ever flight of Virgin Airlines", destination:"london" , airlines:"Virgin Airlines" )

maintenant laisse passer ces exemple de deux fonctions qui modifient l'identification, la description, la destination, etc..

func modifyFlight(flight:Flight) -> Void {
flight.id = 200
flight.description = "second flight of Virgin Airlines"
flight.destination = "new york"
flight.airlines = "Virgin Airlines"
}

aussi,

func modifyFlight2(flight2: Flight2) -> Void {
var passedFlight = flight2
passedFlight.id = 200
passedFlight.description = "second flight from virgin airlines" 
}

donc,

modifyFlight(flight: flightA)
modifyFlight2(flight2: flightB)

maintenant, si on imprime le flightA de l'id et la description, nous obtenons

id = 200
description = "second flight of Virgin Airlines"

Ici, nous pouvons voir l'id et la description de FlightA a changé car le paramètre passé à la méthode de modification renvoie l'adresse mémoire de flightA objet(type de référence).

maintenant, si nous avons l'impression que l'id et la description de FLightB exemple on se,

id = 100
description = "first ever flight of Virgin Airlines"

Ici, nous pouvons voir que la FlightB instance n'est pas modifié parce que dans modifyFlight2 méthode, l'instance réelle de Flight2 est passe plutôt que de référence ( valeur type).

OriginalL'auteur Manoj Karki

Avec les classes que vous obtenez de l'héritage et sont passés par référence, les structures n'ont pas d'héritage, et sont passés par valeur.

Il y a de grandes WWDC sessions sur Swift, cette question est posée dans le détail étroit dans l'un d'eux. Assurez-vous de regarder ceux qui, comme elle, vous obtiendrez jusqu'à la vitesse beaucoup plus rapidement, le guide de Langue ou de l'iBook.

OriginalL'auteur Joride

Dans Swift, un nouveau modèle de programmation a été introduit connu comme le Protocole de Programmation Orienté.

Creational Modèle:

Dans swift, Struct est une types de valeur qui sont automatiquement dupliqués. Par conséquent, nous obtenons le comportement requis pour mettre en œuvre le prototype de modèle pour gratuit.

Alors que classes sont le type de référence, ce qui n'est pas automatiquement clonés au cours de la mission. Pour mettre en œuvre le prototype de modèle, les classes doivent adopter les NSCopying protocole.

Copie superficielle doublons seulement la référence, que des points à ceux des objets, alors que copie en profondeur les doublons de référence de l'objet.

La mise en œuvre de copie en profondeur pour chaque type de référence est devenu une tâche fastidieuse. Si les classes d'inclure d'autres type de référence, nous avons à mettre en œuvre un prototype de modèle pour chacune des références propriétés. Et puis nous avons à copier la totalité de l'objet graphique par la mise en œuvre de la NSCopying protocole.

class Contact{
var firstName:String
var lastName:String
var workAddress:Address //Reference type
}
class Address{
var street:String
...
} 

En utilisant les structures et les énumérations,, nous avons fait notre code plus simple puisque nous n'avons pas à mettre en œuvre la copie de la logique.

OriginalL'auteur Balasubramanian

Structs sont value type et Classes sont reference type

• Types de valeur sont plus rapides que les types de Référence
• Type de la valeur des instances sont en sécurité dans un environnement multi-thread comme
  plusieurs threads peuvent muter l'instance sans avoir à se soucier
  sur les conditions de course ou de blocages
• Type de valeur n'a pas de références à la différence de type de référence; par conséquent, il
  est pas de fuites de mémoire.

Utiliser un value type:

• Vous voulez des copies d'avoir un etat indépendant, les données seront utilisées dans
  code sur plusieurs threads

Utiliser un reference type:

• Vous souhaitez créer partagé, mutable état.

D'autres informations peuvent également être trouvées dans la documentation d'Apple

https://docs.swift.org/swift-book/LanguageGuide/ClassesAndStructures.html

Des Informations Supplémentaires

Swift types de valeur sont conservés dans la pile. Dans un processus, chaque thread a son propre espace de pile, de sorte qu'aucun autre thread ne sera en mesure d'accéder à votre type de valeur directement. Par conséquent, aucune des conditions de course, des serrures, des blocages ou liés à la synchronisation des threads complexité.

Types de valeur n'ont pas besoin d'allocation dynamique de la mémoire ou de comptage de référence, qui sont des opérations coûteuses. Dans le même temps, des méthodes sur des types de valeur sont envoyés de manière statique. Celles-ci créent un énorme avantage en faveur des types de valeur en termes de performances.

Comme un rappel ici est une liste de Swift

Types de valeur:

• Struct
• Enum
• Tuple
• Primitifs (Int, Double, Bool, etc.)
• Collections (Array, String, Dictionnaire, Set)

Types de référence:

• Classe
• Rien venir de NSObject
• Fonction
• Fermeture

OriginalL'auteur casillas

Comme struct sont des valeurs types et vous pouvez créer la mémoire très facilement, ce qui les stocke dans la pile.Struct peut être facilement accessible et d'après l'étendue du travail, il est facilement libéré à partir de la pile de la mémoire par le biais de la pop à partir du haut de la pile.
Sur l'autre main de la classe est un type de référence qui stocke dans le tas et les modifications apportées à un objet de classe aura un impact sur d'autres objets, car ils sont étroitement liés et le type de référence.Tous les membres d'une structure publique, alors que tous les membres d'une classe sont privés.

Les inconvénients de la structure est qu'elle ne peut pas être héritée .

OriginalL'auteur Tapash Mollick