2

この質問は、特に静的ライブラリ/フレームワークに焦点を当てています。つまり、他の人が最終的に触れるコードです。

私は iOS 6 がリリースされたときに iOS 開発を始めたので、プロパティにかなり精通しています。インターフェイス拡張で宣言された隠しプロパティを使用して、「プライベート」プロパティのすべての作業を行いました。readonlyこれには、他の人に変更してほしくない公開プロパティでの使用やreadwrite、インターフェイス拡張内での使用が含まれます。

重要なことは、これらの静的ライブラリ/フレームワークを使用している他の人が、許可しない場合はこれらのプロパティにアクセスしたり、読み取らせた場合にこれらのプロパティを書き込んだりしたくないということです。

理論的には、彼らが独自のインターフェース拡張を作成し、自分のreadonlyプロパティをreadwrite自分で作成したり、隠しプロパティの名前を推測したりできることを、私はしばらく前から知っていました。

これを防ぎたい場合、ivar@privateを直接宣言したタグで ivar を使用する必要がありますか? この方法でそれを行うことの潜在的な失敗はありますか? それは実際に追加のセキュリティ手段を私に与えますか、それとも赤いニシンですか?

4

2 に答える 2

4

ARC では、インスタンス変数ではなくプロパティでサポートされる唯一のモードは、プロパティを使用するcopy必要がある場合ですcopy。

@implementationセクションでプライベート インスタンス変数を宣言すると、次のようになります。

@implementation MyClass
{
   // private instance vars
}

その場合、クラス外からそれらにアクセスするにはかなりの労力が必要です。あなたが言うように、「プライベート」プロパティにアクセスするには、その名前を推測するか、ライブラリ呼び出しを使用するだけです。

セキュリティのためにそれは価値がありますか？YMMV。しかし、それは良いコーディング方法です。

補遺

コメント トレイルが示すように、私の真剣な取り組みについては多くの議論がありました。

まず明確にしましょう。Objective-C は C ファミリーの言語です。これらはすべて、プログラマーが言語内にとどまりながら、選択したほぼすべてのものを使用できるようにします[*] - これらは、強い型付け、アクセスが必要な場合に選択する言語ではありませんコード内の制限など。

第二に、「努力」は絶対的な尺度ではありません！したがって、「深刻」ではなく、「明白」という言葉を選んで修飾するべきだったのかもしれません。プライベート プロパティにアクセスするには、オブジェクトが型を持つ標準的なメソッド呼び出しを使用するだけでid済みます。呼び出されるメソッドが隠されているコードにはほとんど手がかりがありません。プライベート変数にアクセスするには、API 呼び出し (ランタイム関数または KVC 呼び出し) または何らかのポインター操作が必要です。結果のコードは、標準の変数割り当てとはまったく異なります。そのため、より明白です。

つまり、 を必要とする使用を除けばcopy、ARC では、プライベート インスタンス変数で十分な場合にプライベート プロパティを使用する正当な理由はありません。プライベート変数のfred比較:

self.fred = 42;   // property access, may involve a call (if not optimised out)
_fred = 42;       // common way to bypass the accessors and get at the underlying var
fred = 42;        // direct access

正しい答えはありませんが、間違った答えもありません-これは意見の領域です (もちろん、それは意見です ;-))。私はしばしば最後のもの、プライベート変数 - クリーンでシンプルなものを選びます。ただし、@RobNapier は彼の回答でプロパティの使用を好みます。

[*] 注: アセンブラーで記述された外部コードへのリンクを検討すると、すべての賭けは任意の言語で行われます。その時点で、保護を提供するために「ハードウェア」（実際または仮想）および/または「OS」を確認する必要があります。

于 2013-12-18T23:12:53.083 に答える
2

ここでは、プライベート (「非表示」) プロパティを使用する必要があります。「セキュリティ」リスクはありません。このシナリオの「攻撃者」は呼び出し元です。呼び出し元は、プロセス内のすべてのメモリに完全にアクセスできます。彼女はあなたのフレームワーク内の好きなものにアクセスできますが、それを止めるためにあなたができることはまったくありません (あなたもそうすべきではありません)。これはどの言語でも同じです。何をしているのか分かっていれば、C++ でも "private:" の指定をバイパスできます。結局のところ、それはすべて単なる記憶です。

自分自身やフレームワークを呼び出し元から守るのはあなたの仕事ではありません。どちらも同じ目標を持っています: プログラムの動作を正しくすることです。あなたの目標は、発信者を自分自身から保護することです。彼らがあなたのフレームワークを間違って使用するのを難しくし、正しく簡単に使用できるようにします。

したがって、最も正しいコードにつながるツールを使用する必要があります。そして、そのツールはプロパティであり、init と dealloc を除いて ivar への直接アクセスを避けます。

于 2013-12-19T01:38:27.407 に答える