Future & Promises (PromiseKit, Bolts, ...)

2»

Réponses

  • Je n'ai pas tout compris au texte sous la video d'Andy Matuschak. Le concept a l'air interessant mais le texte est confus. Et je n'aime pas les vidéos...

    Ce que j'ai retenu : les objets sont dangereux car ils peuvent etre modifiés à  plusieurs endroits par référence.


    Pour moi le passage de struct à  objet est intuitif. Un objet est vivant (il a un etat) et unique (il est identifié). Les structs sont des regroupements de valeur, anonymes et dont l'identification n'est pas utile.

    T

    Cependant, en travaillant de plus en plus avec les bases de donnees et le web, j'ai remarqué que les objets du model avait tendance à  devenir inerte. Et du coup on utilise des pattern type visitor pour donner de la vie aux objets.

    J'ai l'impression qu'on revient à  la programmation à  base de struct qu'on pratiquait en C avant la POO où le code était bien séparé des données.
  • Apple conseille d'utiliser les structures pour des modèles simples et les classes pour les autres. La plupart du temps il faut utiliser les classes selon Apple. 


     


    Doc :


    C'est dans le livre Swift. (“Choosing Between Classes and Structures”).

  • AliGatorAliGator Membre, Modérateur
    La règle est simple.
    Structure pour les données pures à  utiliser en tant que Value Types.
    Classes quand tu as absolument besoin de l'aspect Reference Types.

    La vidéo d'Andy l'explique quand même bien les avantages et inconvénients de chaque solution.
Connectez-vous ou Inscrivez-vous pour répondre.