シングルトンの構造体で自己を使用する

Question

シングルトンについて簡単な質問がありますが、多くの研究の後に私はそれについて明確な答えが見つかりませんでした。そこで、質問です - 私はStructAを持っている：

struct StructA { 
    static let shared = StructA() 

    private init() {} 

    public func someFuncA() { 
     //self.somefuncB() 
     //or 
     //StructA.shared.someFuncB() 
    } 

    private func someFuncB() { 

    } 
} 

私はこのStructA.shared.someFuncA()ような他のクラスからsomeFuncAを呼び出す：

1. あなたは違いself.somefuncB()とStructA.shared.someFuncB()は（コードの上を参照）ものを私に説明してくださいできますか？ は、私の意見では違いはありませんが、私はself.somefuncB()がコールバックで呼び出される必要があり、そのようなコード持っているものならば -

2. をだから私は[weak self]を使用する必要がありますか？

   public func someFuncA() { 
       someFuncWithCallback() { [weak self] in 
        self?.somefuncB() 
       } 
   } 
   

   または私はちょうど

   public func someFuncA() { 
       someFuncWithCallback() { 
        StructA.shared.someFuncB() 
       } 
   } 
   

   を書くことができます私は近い/ブロックで使用されるオブジェクトを所有している知っているように、それは、全く漏れがないことを言う「リーク」（Xcodeの楽器）と、このコードをチェックしますそれで、誰かが私にここで何が起こるか説明できますか？ありがとう。

Answer 1

思考のカップル：

1. structシングルトンは点では矛盾です。シングルトンは、インスタンスが1つだけでなければならないオブジェクトです。しかし、structは値型で、 "コピー"メモリセマンティクスを持っています。考えてみましょう：

   var a = StructA.shared 
   a.foo = 42    // let's assume you had added a `var foo: Int` property to `StructA` 
   

   aいわゆるシングルトンのコピーではなく、それへの参照です。 fooプロパティはコピーに設定されますが、元の "シングルトン"は設定されません。この問題を回避するには、シングルトンを参照型のclassにする必要があります。

2. 私はPaulw11に同意します。つまり、selfはより簡単で一般的なアプローチです。私はまた、selfを参照することによって、シングルトンであるクラスに依存しないコードを書く方が良いことを示唆しています。私はselfパターンを助言することを考えると

3. 、私は、したがって、（例えば、必要な場所weakまたはunowned参照を使用することによって）明らかに潜在的な強い参照サイクルを避けることを示唆しています。単純にシングルトンになるため、単純に強力なリファレンスサイクルとなるものを意図的に作成する必要はありません。なぜシングルトンパターンを使用するかの決定を再訪した場合、特に最初に強い参照を避けるのが簡単であることがわかっている場合に書き直す必要があることを知っているコードを書くのですか？

4. 実際には、staticが理論的な強い参照サイクルに参加しても、そのように特定されていないことが報告されています。しかし、staticプロパティをnilに設定すると（それが可変でオプションであると仮定して）、強い参照が表示されます。

   上記の推奨事項は変更されていません。つまり、他のコンテキストでの強い参照サイクルになることを避けるためです。私は単にあなたの経験的な観察を確認しているだけです。

に関して点（私はいくつかの他のパタ​​ーンにシングルトンパターンのいくつかの潜在的な最終的なリファクタリングを企図）上記2〜4は、私は、これは純粋に学術的観察ではないと言うべきです。いくつかのシングルトンタイプを持つことは珍しくなく、プロジェクトがより複雑になったり、より多くの単体テストを採用したりして、その決定を再訪したり、依存性注入やその他のパタ​​ーンを採用したりすることは珍しいことではありません。個々の機能のすべてを編集しなければならないのは残念です。オブジェクトのシングルトンの性質に依存しないようにコードを書くと、不必要な内部依存が少なく、より堅牢なコードベースになります。