Tableau facultatif vs tableau vide dans Swift

J'ai un simple Person classe Swift qui ressemble à quelque chose comme ceci:

class Person {
    var name = "John Doe"
    var age = 18
    var children = [Person]?

    \\ init function goes here, but does not initialize children array
}

Au lieu de déclarer children être un tableau facultatif, je pourrais simplement déclarer et initialiser un tableau vide comme ceci:

var children = [Person]()

Je suis en train de décider quelle approche est la meilleure. La déclaration du tableau comme un tableau facultatif signifie qu'il ne va pas prendre de la mémoire à tous, alors que l'un tableau vide a au moins de la mémoire allouée pour lui, correct? Donc, en utilisant le tableau optionnel signifie qu'il y aura au moins de la mémoire de l'épargne. Je suppose que ma première question est: Est-il vraiment aucune mémoire réelle économie en cause ici, ou sont mes hypothèses à propos de ce incorrect?

D'autre part, si elle est facultative, alors, chaque fois que j'essaie de l'utiliser, je vais avoir à vérifier pour voir si elle est nil ou non avant d'ajouter ou de supprimer des objets à partir d'elle. Donc, il y aura une perte de l'efficacité de là (mais pas beaucoup, j'imagine).

J'aime bien l'option d'approche. Pas tous les Person aura des enfants, pourquoi ne pas les laisser children être nil jusqu'à ce que le Person décide de s'installer et de fonder une famille?

En tout cas, je voudrais savoir si il y a des autres avantages ou les inconvénients d'une approche ou l'autre. C'est une question de conception qui va venir encore et encore.

  • Vous avez une question valable, mais je pense que les arguments pour et contre sont dangereux basé sur l'optimisation prématurée et non sémantique. Il est de loin préférable de se concentrer sur la "affordance" du code - combien il suggère l'intention (quoi que peut-être pour le contexte). Il y a un tas de choses que je n'aime pas à propos de Swift, mais pour moi, l'Option type est un véritable bijou. Il n'existe pas de "bonne" réponse à votre question, je l'utilise largement dans des contextes comme la vôtre. À l'aide d'une option pour le cas de l'option d'enfants semble tout à fait raisonnable et minimaliste.
  • Je suppose que le nombre d'éléments dans la matrice de zéro signifie qu'il ya zéro des enfants. Un néant tableau voudrais suggérer qu'il existe un certain nombre d'enfants qui ne peuvent pas être égal à zéro et ne peut pas être non nulle. Il n'y a pas de logique dans le retour de néant, car il n'y a pas de sens en elle. Ayant dû maintenir le code qui a été écrit il y a 20 ans, je peux vous dire que si vous suggérer d'autres sens, en retournant néant, certains seront confus par elle et me demande ce que vous avez l'intention de faire avec ce néant qu'un tableau vide n'a pas d'accomplir. les performances du tableau vide n'est pas susceptible d'affaire.
InformationsquelleAutor Aaron Rasmussen | 2014-11-07
  1. 15

    La possibilité de choisir entre un tableau vide ou une option qui nous donne la capacité d'appliquer l'une que de mieux décrire les données à partir d'un point de vue sémantique.

    Je choisirais:

    • Un tableau vide si la liste peut être vide, mais c'est un statut transitoire et à la fin, il doit disposer d'au moins un élément. Non facultatif est clair que le tableau ne doit pas être vide
    • Facultatif si il est possible que la liste soit vide pour l'ensemble du cycle de vie du conteneur de l'entité. Être une option précise que l'ensemble peut être vide

    Permettez-moi de faire quelques exemples:

    • Ordre d'achat avec le maître et les détails (un détail par produit): un ordre d'achat peut avoir 0 de détails, mais c'est un statut transitoire, car il ne serait pas logique d'avoir un ordre d'achat avec 0 produits
    • Personne avec des enfants: une personne peut ne pas avoir d'enfant pour toute sa vie. Ce n'est pas un statut transitoire (bien que n'étant pas permanente ainsi), mais en utilisant une option, il est clair qu'il est légitime qu'une personne n'ont pas d'enfants.

    Remarque que mon opinion est seulement à rendre le code plus clair et de soi-même - je ne pense pas qu'il n'y a aucune différence significative en termes de performance, l'utilisation de la mémoire, etc. pour le choix de l'une ou l'autre.

    • Le nombre d'éléments dans le tableau est le nombre d'enfants. Zéro éléments est égal à zéro les enfants. À l'aide de néant pour le tableau implique un nombre ni zéro ni non nul, ce qui est presque absurde. Le seul cas où le néant peut avoir du sens est, si vous voulez transmettre à l'appelant que le nombre ne peut être calculée (inconnu), qui est le seul autre état possible. Retourne le nombre d'enfants si le nombre est connu et le retourner par avoir que de nombreux éléments dans le tableau.
    • "Une option si il est possible que la liste soit vide pour l'ensemble du cycle de vie du conteneur entité" c'est quelque chose Que je n'aurais jamais pense donc à l'aide de néant pour qui n'est pas intuitif, et aurait besoin d'un commentaire. En fait, toute utilisation de nul aurait besoin d'un peu de code commentaires me faisant penser que c'est mieux de tout simplement ne pas l'utiliser et renvoie un tableau vide, ce qui est totalement clair et ne nécessite pas de commentaires dans le code pour comprendre.
    InformationsquelleAutor Antonio
  2. 19

    Je vais faire l'inverse de Yordi - un tableau vide comme dit clairement: "cette Personne n'a pas d'enfants", et vous permettra d'économiser une tonne de tracas. children.isEmpty est facile de vérifier l'existence d'enfants, et vous ne jamais avoir à déballer ou de se soucier d'une inattendue nil.

    Aussi, comme une note, déclarer que quelque chose comme option ne signifie pas qu'il prend zéro de l'espace - c'est le .None cas d'une Optional<Array<Person>>.

    • Tout à fait d'accord. Rendant facultative l'oblige également à faire deux de vérifier si nous vraiment vous voulez savoir si il y a plus de 1 enfant (unwrap de vérifier ensuite si elle n'est pas vide), ce qui complique légèrement le code sans de réels avantages. Tableau vide est clair à mon avis.
    • Je me demande au sujet de problèmes de performances, si j'ai un lourd classe, un tableau de ce type d'être une grosse surcharge par rapport à un .Aucun? Ou est-il tout d'optimisation de Swift de ne pas allouer de l'espace pour d'abord des tableaux vides?
    InformationsquelleAutor Nate Cook
  3. 12

    Assez intéressant, nous avons récemment eu quelques discussions à propos de cette même question de la au travail.

    Certains suggèrent qu'il y a de subtiles différences sémantiques. E. g. nil désigne une personne n'a pas d'enfants que ce soit, mais alors qu'est-ce 0 veux dire? Signifie-t-il "a des enfants, l'ensemble de l'0 d'entre eux"? Comme je l'ai dit, la sémantique pure "a 0 enfants" et "n'a pas d'enfants" ne fait aucune différence lorsque l'on travaille avec ce modèle dans le code. Dans ce cas, pourquoi ne pas choisir plus straightforwards et moins de la garde-laissez-?-y approche?

    Certains suggèrent que le maintien d'un nil il y a peut être une indication que, par exemple, lors de l'extraction de modèle de backend quelque chose s'est mal passé et nous avons eu d'erreur à la place des enfants. Mais je pense que le modèle ne devrait pas essayer d'avoir ce type de sémantique et de nil ne doit pas être utilisé comme une indication d'une erreur dans le passé.

    Personnellement, je pense que le modèle doit être aussi stupide que possible et le plus bête option dans ce cas est vide.

    Avoir une option fera de vous glisser que ? jusqu'à la fin de jours et d'utiliser guard let, if let ou ?? encore et encore.

    Vous aurez pour avoir un supplément de déballage de la logique pour NSCoding mise en œuvre, vous aurez à faire person.children?.count ?? 0 au lieu de simple person.children.count lors de l'affichage de ce modèle dans une vue contrôleur.

    Le but final de tout ce que la manipulation est d'afficher quelque chose sur l'INTERFACE utilisateur.
    Voulez-vous vraiment dire

    "Cette personne n'a pas d'enfants" et "Cette personne a 0 enfants" pour nil et tableau vide en conséquence? J'espère que vous ne serait pas 🙂

    Dernière Paille

    Enfin, et c'est vraiment l'argument le plus fort que j'ai

    Il y a des tonnes d'exemples de ce genre dans le cadre de Cacao: UIViewController::childViewControllers et plus.

    Même de la pure Swift monde: De dictionnaire::touches si cela peut être un peu tiré par les cheveux.

    Pourquoi est-il OK pour personne à avoir nil enfants, mais pas pour SKNode? Pour moi, l'analogie est parfaite. Hey, même les SKNode's nom de la méthode est children 🙂

    Mon point de vue: il doit y avoir une raison évidente pour garder ces tableaux comme des options, comme une vraiment bonne, sinon tableau vide offre même de la sémantique avec moins de déballage.

    La Dernière Goutte D'Eau

    Enfin, des références à de très bons articles, chacun de ces

    Dans Natasha post, vous trouverez une lien vers NSHipster du blog et dans Swiftification paragraphe, vous pouvez lire ceci:

    Par exemple, au lieu de marquer NSArray valeurs de retour comme nullable, de nombreuses Api ont été modifiés pour retourner un tableau vide—sémantiquement elles ont la même valeur (c'est a dire rien), mais non en option tableau est beaucoup plus simple de travailler avec

    • "néant" pour moi, c'est la valeur null dans la base de données ( la même que java et c#'s les valeurs null). Cela signifie que nous ne savons pas si la personne a des enfants ou pas. Une valeur de 0 signifie que nous savons que la personne n'a pas d'enfants.
    • c'est un bon exemple où nil de sens que dans le domaine du problème. J'aurais quand même dire que si il n'y a pas besoin de modèle de la "nous ne savons pas" ou similaire, état, alors il n'y a pas besoin d'utiliser nil. E. g. dans les applications bancaires, nous (la banque) savez certainement que le client dispose de comptes, de sorte nil et tableau vide aurait même sémantique. Même avec SKNode, le SpriteKit cadre ne sait pour sûr si un nœud a des enfants ou non, de sorte qu'ils modèle comme tableau vide.
    • tout à fait d'accord et c'est pourquoi ils nous donnent la possibilité de marquer une colonne de valeurs null dans les systèmes sgbdr et pourquoi il était nécessaire d'avoir nullable variables dans les langages de programmation comme swift/java/c# etc
    InformationsquelleAutor i4niac
  4. 5

    Parfois il y a une différence entre quelque chose n'existant pas et d'être vide.

    Disons que nous avons une application où l'utilisateur peut modifier une liste de numéros de téléphone et de nous enregistrer les modifications que modifiedPhoneNumberList. Si aucune modification n'a jamais eu lieu, le tableau doit être nul. Si l'utilisateur a modifié l'analyse des nombres en les supprimant toute la table doit être vide.

    Vide signifie que nous allons supprimer tous les numéros de téléphone, nul signifie que nous garder tous les numéros de téléphone actuels. La différence ici.

    Quand on ne peut pas différencier entre une propriété vide ou n'existe pas ou il n'a pas d'importance vide est le chemin à parcourir. Si un Person devaient perdre leur seul enfant, nous devrions tout simplement à supprimer cet enfant et avoir un tableau vide plutôt que d'avoir à vérifier si le count est 1 puis définissez l'ensemble de la matrice de nil.

    • C'. Avoir des options vous permet aussi de comprendre (dans une certaine mesure) l'histoire d'une variable. Comme Deco dit, si vous avez une option d'enfants tableau qui est vide, cela signifie que la Personne a eu des enfants, mais en quelque sorte perdu à un certain point. Dans les conditions de l'INTERFACE utilisateur, vous pouvez ensuite différencier "Personne n'a jamais eu d'enfants" à partir de "Personne n'a pas plus des enfants'
    InformationsquelleAutor Declan McKenna
  5. 2

    J'ai toujours utiliser des tableaux vides.

    À mon humble avis, l'objectif le plus important des options dans Swift est en toute sécurité enveloppez de la valeur qui peut être nul. Un tableau déjà que ce type de wrapper - vous pouvez demander au tableau s'il a quelque chose à l'intérieur & accéder à sa valeur(s) en toute sécurité avec les boucles for, cartographie, etc. Faut-il mettre une enveloppe dans une enveloppe? Je ne le pense pas.

    InformationsquelleAutor Trev14
  6. 1

    Swift est conçu pour tirer parti de la valeur facultative et option de déballage.

    Vous pourrait également déclarer le tableau en tant que néant, qu'il vous fera économiser un très faible (presque pas perceptible) quantité de mémoire.

    Je voudrais aller avec une option de tableau au lieu d'un tableau qui représente une valeur nulle pour garder Swift Modèles de Conception heureuse 🙂

    Je pense aussi 

    if let children = children {

}

    ressemble de plus agréable que de : 

    if(children != nil){

}
    InformationsquelleAutor Yordi