GameManager : Pourquoi Class à la place de Struct

Hello,

Dans le Chapitre 4.2 du cour sur SwiftUI 2020, Maxime crée dans le fichier « GameManager » une Class alors que depuis le début de la création de l’application nous creons des Struct.

Pourquoi avoir choisi un class au lieu d’une struct à ce moment là ? Et plus généralement comment faire son choix ?

J’ai compris la théorie sur le choix de l’un ou de l’autre, mais en pratique je ne vois pas.

merci

Les données des structures sont fixes. On ne peut pas les changer pendant l’exécution de l’application (enfin si, mais c’est compliqué à faire, nécessitant d’ajouter des fonctions supplémentaires à la structure)

On ne s’en rend pas trop compte dans les exercices, car l’attribut @State des View de SwiftUI rend les variables modifiables. Le but de l’exercice de Maxime est d’externaliser les variables, de les stocker dans une structure de données extérieure, pour bien séparer les aspects affichages et stockages des données.

Les variables publiques d’une classe sont modifiables, ce qui en fait un bon outil pour créer un container externe de stockage des données.

Il y a aussi une raison historique, on n’utilise pratiquement que des classes dans les langages objets. Toutes les applications développées avec l’ancien outil (Storyboard + UIKit) sont a base de classes. Penser dés le début qu’une application est une association de View SwiftUI et de classes d’objets « classiques » aide à la transition entre les deux outils.

Un débutant ne cherchant qu’à developper des applications par lui-même, ou dans une petite structure n’aura pas à se préoccuper de ça. Mais un développeur voulant en faire son métier de manière sérieuse aura certainement à gérer la transition d’applications UIKit vers SwiftUI pendant … longtemps, 5 à 10 ans au moins !

Il y a peu de différences entre les classes et les structures en Swift ; une différence importante est que lorsque les classes sont passées comme argument, dans une méthode, par exemple, elles sont passées par référence. On ne le voit pas, mais c’est un pointeur qui est passé. En ce qui concerne les structures, elles sont passées par valeur, et ça change beaucoup de choses.

Par exemple, une instance de classe peut faire l’objet de plusieurs références différentes, elle peut être « deinitialized » et libérer les ressources qu’elle mobilise en mémoire, et le type d’une instance de classe peut être interprété comme tel au moment de l’exécution.
Apple recommande de choisir les structures par défaut, mais recommande les classes lorsque l’on a besoin d’interagir avec Objective-C, lorsqu’on doit identifer les données que l’on utilise comme appartenant à telle classe, ou lorsqu’on a besoin de recourir à l’héritage. Les structures ne connaissent que le seul héritage ayant lieu à travers un protocole, elles ne peuvent hériter qu’à travers un protocole.

Ça peut paraître compliqué, l’essentiel est lié à
instance de classe = passée par référence
structure = passée par valeur

Ne te laisse par impressionner par le charabia, essaye et si l’un ne va pas, vois avec l’autre. À un moment, tu pigeras ce qu’il en est intuitivement, ce n’est pas si grave.

1 « J'aime »

Merci pour vos réponses :slight_smile: