N'Swift ont des modificateurs d'accès?

Question

En Objective-C exemple de données peuvent être public, protected ou private. Par exemple:

@interface Foo : NSObject
{
  @public
    int x;
  @protected:
    int y;
  @private:
    int z;
  }
-(int) apple;
-(int) pear;
-(int) banana;
@end

Je n'ai pas trouvé de mention de modificateurs d'accès à la référence Swift. Est-il possible de limiter la visibilité des données de Swift?

Answer 1

Edit: mécanismes de contrôle d'Accès ont été introduites dans Xcode 6 bêta 4 (6A267n):

Swift de contrôle d'accès dispose de trois niveaux d'accès:

• private entités ne peut être accessible à partir du fichier source où elles sont définies.
• internal entités peut être consulté n'importe où à l'intérieur de la cible où ils sont définis.
• public entités peut être consulté à partir de n'importe où à l'intérieur de la cible et à partir de n'importe quel autre contexte que les importations de la cible actuelle du module.

---

J'ai été la navigation des Développeurs d'Apple Forums et trouvé ce fil, où @gparker (une Pomme ingénieur) dit que:

Swift n'a pas actuellement de mécanismes de contrôle d'accès.

Cependant, après quelques plaintes, il déclare:

Nous n'avons pas l'habitude de promettre quelque chose pour l'avenir, mais dans ce cas, nous faisons une exception. Swift aura mécanismes de contrôle d'accès.

C'est certainement de bonnes nouvelles. :)

Answer 2

J'ai dit au maître: "je comprends maintenant! Les fermetures sont le pauvre homme modificateurs d'accès." Il m'a battu, en disant: "Combien de fois dois-je vous dire, modificateurs d'accès sont le pauvre homme d'encapsulation!" Et j'ai été éclairé.

Answer 3

Lorsque l'on parle de prendre une "méthode" de Swift ou ObjC (ou ruby ou java, ou...), ces méthodes ne sont pas vraiment privé. Il n'y a pas de réel contrôle d'accès autour d'eux. Une langue qui offre tout de même un peu d'introspection permet aux développeurs d'obtenir ces valeurs à partir de l'extérieur de la classe, si ils veulent vraiment.

Donc, ce que nous sommes réellement en train de parler ici est un moyen de définir un public interface simple présente les fonctionnalités que nous voulons, et "cache" du reste ce que nous considérons comme "privé".

La Swift mécanisme permettant de déclarer des interfaces est l' protocol, et il peut être utilisé à cette fin.

protocol MyClass {
  var publicProperty:Int {get set}
  func publicMethod(foo:String)->String
}

class MyClassImplementation : MyClass {
  var publicProperty:Int = 5
  var privateProperty:Int = 8

  func publicMethod(foo:String)->String{
    return privateMethod(foo)
  }

  func privateMethod(foo:String)->String{
    return "Hello \(foo)"
  }
}

Rappelez-vous, les protocoles sont les premiers types de classe et peut être utilisé n'importe où un type peut. Et, lorsqu'il est utilisé de cette façon, ils n'exposent que leurs propres interfaces, et non pas ceux de la mise en œuvre de type.

Ainsi, aussi longtemps que vous utilisez MyClass au lieu de MyClassImplementation dans vos types de paramètres, etc. il devrait tout juste travail:

func breakingAndEntering(foo:MyClass)->String{
  return foo.privateMethod()
  //ERROR: 'MyClass' does not have a member named 'privateMethod'
}

Il y a certains cas de l'affectation directe où vous devez être explicite avec le type au lieu de s'appuyer sur Swift à déduire, mais cela ne semble guère un briseur d'affaire:

var myClass:MyClass = MyClassImplementation()

En utilisant des protocoles de cette façon, la sémantique, raisonnablement concis, et à mes yeux ressemble beaucoup à la Classe Extentions nous avons été en utilisant à cette fin en ObjC.

Answer 4

Aussi loin que je peux dire, il n'y a pas de mots clés "public", "privé" ou "protégé". Cela donnerait à penser que tout est public.

Toutefois, Apple peut être attendre que les gens à utiliser des "protocoles" (appelées interfaces par le reste du monde) et l' usine modèle de conception pour masquer les détails de la mise en œuvre de type.

C'est souvent un bon modèle de conception à utiliser de toute façon; car il vous permet de modifier votre mise en œuvre hiérarchie de classe, tout en gardant la logique de système de type identique.

Answer 5

En utilisant une combinaison de protocoles, de fermetures, et imbriquée/classes internes, il est possible de l'utiliser quelque chose le long des lignes du motif de module de cacher des informations dans Swift droit maintenant. Ce n'est pas super propre ou agréable à lire mais il fonctionne.

Exemple:

protocol HuhThing {
  var huh: Int { get set }
}

func HuhMaker() -> HuhThing {
   class InnerHuh: HuhThing {
    var innerVal: Int = 0
    var huh: Int {
      get {
        return mysteriousMath(innerVal)
      }

      set {
       innerVal = newValue / 2
      }
    }

    func mysteriousMath(number: Int) -> Int {
      return number * 3 + 2
    }
  }

  return InnerHuh()
}

HuhMaker()
var h = HuhMaker()

h.huh      // 2
h.huh = 32 
h.huh      // 50
h.huh = 39
h.huh      // 59

innerVal et mysteriousMath sont cachés ici, à partir d'une utilisation à l'extérieur et à tenter de creuser votre chemin dans l'objet doit provoquer une erreur.

Je suis seulement une partie de la voie à travers ma lecture de la Swift docs donc si il y a une faille ici s'il vous plaît le signaler, aimerait savoir.