プライベート変数の@propertiesをメモリ管理の利点のために作成するのは悪いですか？メモリ管理のメリットのためだけにプライベート変数に@propertiesを使用するのは「悪い」ですか？
多くのプライベート変数に対して@propertiesを公開するのは面倒で間違っているようです。
（主に、私はそれぞれの「イベント」メソッドを使用してメモリ不足状態の間にプライベートアイバーズをリリースしています。）
例： 私は通常、民間IVARを解放するために、この操作を行います。
[name release]; name = nil;
しかし@propertiesで、私はこれを行うことができます、その後、私のコードで
self.name = nil;
を、したがって、これを行いますnilに設定する必要があります：パブリックプロパティの場合
if(!name)
name = [[NSString alloc] initWithFormat:@"Hi %@",inputName];
代わりに、プロパティを非公開にすることもできます。あなたは、クラス内のプロパティのみがアクセスできるようにする（自分の.mファイルでの）次のコードを使用することができます。
#import "MyClass.h"
@interface MyClass()
@property (retain) NSString* privateString;
@end
@implementation MyClass
@synthesize privateString;
// Your code here
@end
は今、あなたは、プロパティのしやすさを持っているが、他のクラスはまだそれにアクセスすることはできません彼らがあなたの.hファイルをインポートしたとしても！
時々nilにプロパティを設定するだけで、変数（KVO通知、またはカスタムを解放以外の副作用を持つことができるので、私は、Appleがそれを推奨していないと思います他の何かをするsetterメソッド）。
私有財産については、あまりよく分かりません。プロパティを使用すると、コーディング中にキーストロークを保存するだけで済みますが、少し複雑で壊れやすくなります。あなたが長期的に時間を節約するので、私は可読性と保守性を利便性よりも優先します。
アップルのUIViewControllerドキュメントからの引用 - メソッドのクラスリファレンス - （void）viewDidUnload： "オブジェクトの所有権（アウトレットのものも含む）を放棄するための好ましい方法は、対応するアクセサメソッドを使用して、オブジェクトは無し " – bentford
私はそれが悪いと思った元の理由を見いだすために私は周りを見回した（私は忘れてしまったので）、そして私はこれを見つけた：http://stackoverflow.com/questions/192721/why-shouldnt-i-use- obective-c-2-0-access-in-init-deallocを使用します。それはinitまたはdeallocの唯一の懸念事項であるようです。 –
お客様の便宜のために、プロパティが存在します。あなたのクラスに存在するプロパティを他の人が使用しないようにするには、それらを文書化しないでください。
しかし、それらはあなたの.hファイルに表示されます。 andyvn22にはこれに対する代替の解決方法があります。 – bentford
これは素晴らしいですが、ハックのようです。私は自分のコードでこれを行うつもりはないと思っていますが、少なくとも私が今やっていることの代替案があることを知っています。ありがとうございました！！ – bentford
ハックではなく、エクステンションと呼ばれるカテゴリの明示的な形式です。。 「クラスが公に宣言されたAPIを持っていて、そのクラスが存在するクラスまたはフレームワークだけが使用するために非公式に宣言された追加のAPIを持つことは一般的です」 –
これは絶対にハックではなく、100％なぜ最初にクラス拡張がその言語に追加されたのか。このパターンを喜んで受け入れる。 – bbum