2012-03-30 17 views
0

私は多くのオブジェクトが同じクラスの保存データを参照しています。これまでのプログラムでは、シングルトンを使用しましたが、その習慣を放棄しようとしており、必要なときには最後の手段として使用しています(主に悪評を持っています(過去に悪用しました)。シングルトンではなく弱い「割り当て」参照

しかし、私の新しい技術がどれほどの利点があるのだろうかと思っています。私は単純に同じデータセットへの弱い参照を作成するので、クラスの束は同じメモリを指し、必要に応じてデータを取得します。例えば:クラスのカスタムinit

@property (nonatomic, assign) MyDataClass*mydata;

、それからpropertyこの基準に割り当てる、方法パラメータとして参照を渡します。

これは有効な、受け入れられる方法ですか?私は、シングルトンを使用してこれを行う組織の利点の多くを見つけるのが難しいです。

+0

なぜ、これは 'retain'ではなく' assign'ですか? – Chuck

+0

弱参照であり、クラスがオブジェクトを所有していないため – johnbakers

答えて

0

使用するパターンはうまくいきます。このパターンは、参照カウントやその他の高度なメモリ管理ツールを使用しないすべての標準C++プログラムで使用されます。唯一のことは、オブジェクト階層が参照の弱点、すなわちその参照の後ろにあるオブジェクトに対する参照を持つオブジェクトの依存性を厳密に尊重していることを保証することです。言い換えれば、参照の所有者が削除されていることを常に確認する必要があります。の前に参照が必要です。参照カウントを使用していないため手動で行う必要があります。

これは、オブジェクトのライフタイム全体を常に制御する必要があるため、プログラマにとってより多くの責任を負うことを意味します。弱い参照を持つコードから元のオブジェクトがまだ存在するのか削除されたのかを知ることができないので、パターンを間違えてしまうのは簡単です。設計パターンでこれを保証しなければなりません。

このような理由から、retainタイプのプロパティで制御不能になる可能性のあるオブジェクトへの弱い参照を持つ(つまり、プロパティの値があなたのオブジェクト)、autoreleaseまたはARCです。

プログラマからこの責任を取り除き、安全なコードを書きやすくするために参照カウントが導入されました。あなたのパターンは大丈夫です、それは何百万ものC++プログラムで使用されていますが、あなたの責任を意識する必要があります。

0

原則として、複数のオブジェクトが存在すると理解できないオブジェクトに対しては、シングルトンクラスのみを使用してください。さもなければ、カップリングを導入するので避けるのが最善です。シングルトンを使用するすべてのクラスはシングルトンに密接に結び付けられます。

品物への参照を渡すのは問題ありません。それらは、保持サイクルを回避するために必要な場合を除いて、もちろん弱い参照である必要はありません。

多数のクラス間で同じオブジェクトを渡していることがわかっている場合は、責任の分割とアプリの再構築について考えてみることをおすすめします。

0

シータンの保持/割り当てと使用は、互いに排他的なパターンではありません。私はシングルトンに対してそれほど躊躇しないだろう、私がiOSを始めた当初だった。

Java Webアプリケーションの開発者であることから、シングルトンは密結合のために悪かった。特に、ロードバランサ/(クラウド)にアプリケーションを配布したいのであれば、シングルトンはボトルネックとなり、容易にスケーラブルではありません。

シングルトンを使用したユニットテストにも問題があり、テスト中に状態をリセットしなければならない、またはそれをモックしようとするときにも問題がありました。

しかし、Objective-CとiOS開発では、シングルトンには多くの欠点がありません。あなたのアプリは拡大縮小されず、sdkはすでにシングルトンで散らばっているので、単体テストを妨げることになります。

関連する問題