オープンソースプロジェクトにカスタムカテゴリを含めるべきですか？

Question

オープンソースと考えられるプロジェクトを構築しています。私はx、y座標、または幅を設定するための簡単なアクセサを与えるUIViewカテゴリがあり、フレームを扱わずにUIViewに直接置かれています。 私はソースをオープンしようと思っていますが、プロジェクトでそのようなカテゴリを使用するべきですか？

プロジェクトの多くは

- (void)setLeft:(CGFloat)left; 

または

- (void)setX:(CGFloat)x; 

などのUIViewのための方法と同様のカテゴリを持っていますそして、私は2つのカテゴリがメソッドを作成する場合、あなたは何の保証もありませんということであることを理解しますそのことについてはお呼びになるでしょう。

...どうすればいいですか？カテゴリを一切使用せず、オープンソースプロジェクトでこの厄介なコードを処理しますか？カテゴリを使用し、メソッド名の前に接頭辞を付けることもできます

ありがとうございました！

Answer 1

これらのメソッドを追加する必要はありません。

これは、入力する必要がありません。実際に追加するプレフィックスは醜いでしょう。また、追加されたAPIに対して書かれたコードを作成している間は、実質的な利便性はほとんどありません。

また、一連の便利な方法を使用すると、サブクラス化するのがはるかに難しくなります。どのメソッドをオーバーライドする必要がありますか？ KVOの行動は何ですか？基本的な方法がありますが、すべてが流通しているのですか、それともすべてを無効にする必要がありますか？

フレームワークでは、一般に、このような便利なAPIは追加されません。これは、前述のすべての問題を引き起こしながら、APIに余分な「重み」を作成するためです。これらの追加メソッドは、プロジェクトに新しい人を紹介するときに、開発者が他の人に学び、覚えて説明するだけのデータポイントです。

例外はクラスクラスタクラスです。 NSString、NSArrayなど。彼らは、残りのAPIを実装するために必要なすべての機能を提供する基本的なメソッドのコアセットを持っています。抽象クラスの残りのメソッドは、それらのプリミティブメソッドに関して完全に実装されています。サブクラス化するときは、プリミティブを実装するだけで、他のすべての動作は「うまく動作します」。ただし、サブクラスは、プリミティブ以外のものを自由にオーバーライドして最適化やカスタマイズを行うことができます（ただし、注意してください）。

通常の経験則では、コンビニエンスAPIが数行以上のコードを定期的に保存しなければ、それは価値がありません。

Answer 2

Objective Cはネームスペースをサポートしていないため、共有する予定がある場合はコードを固有のものにするための一般的な方法は、プロジェクトに関連するいくつかの手紙でプレフィックスを付けることです。

setLeftとsetXの名前をLMSetLeftとLMSetXに変更すると、衝突の可能性を大幅に減らすことができます。

これは、IDEのリファクタツールを使用している限り、本当に簡単に変更する必要があります。