私は、オープンソースを検討する可能性のあるプロジェクトを構築しています。x、y座標、または幅を設定するための簡単なアクセサーを提供するUIViewカテゴリがあり、フレームを処理せずにUIViewに直接残しました。私の質問は、プロジェクトをオープン ソース化する予定がある場合、プロジェクトでそのようなカテゴリを使用する必要があるかどうかです。
多くのプロジェクトには、UIView のようなメソッドを持つ同様のカテゴリがあります。
- (void)setLeft:(CGFloat)left;
また
- (void)setX:(CGFloat)x;
そして、私の理解では、2 つのカテゴリがメソッドを作成した場合、どちらが呼び出されるかについての保証はありません。
それで...どうすればいいですか？カテゴリをまったく使用せず、オープン ソース プロジェクトでこの厄介なコードを処理しますか? カテゴリを使用して、メソッド名にプレフィックスを付けますか?
ありがとうございました！
これらのメソッドを追加する必要はありません。
入力をほとんど節約できず、実際に追加する必要がある接頭辞は醜いものになり、追加された API に対して記述されたコードをそれがないプロジェクトに移植できなくなる一方で、実質的な利便性はほとんど追加されません。
同様に、便利なメソッドがたくさんあると、サブクラス化が非常に難しくなります。どのメソッドをオーバーライドする必要がありますか? KVOの挙動は？すべてが通過する原始的な方法はありますか、それとも本当にすべてをオーバーライドする必要がありますか?
フレームワークは通常、このような便利な API を追加しません。これは、上記のすべての問題が発生する一方で、API に多くの余分な「重み」が生じるためです。これらの余分なメソッドはすべて、開発者が新しい人をプロジェクトに紹介するときに学び、覚え、他の人に説明する必要がある単なるデータポイントです。
1 つの例外は、クラス クラスタ クラスです。NSString、NSArray など...これらには、残りの API を実装するために必要なすべての機能を提供する基本的なメソッドのコア セットがあります。抽象クラスの残りのメソッドは、これらのプリミティブ メソッドに関して完全に実装されます。サブクラス化するときは、プリミティブを実装するだけで、他のすべての動作が「そのまま機能」します。ただし、サブクラスは、最適化またはカスタマイズの目的で非プリミティブを自由にオーバーライドできます (ただし、実際には動作を保持する必要があります)。
一般的な経験則では、便利な API が定期的に数行以上のコードを節約しない場合、その価値はありません。
Objective C は名前空間をサポートしていないため、共有を計画している場合、コードが一意であることを確認する一般的な方法は、プロジェクトに特に関連するいくつかの文字をメソッドの前に付けることです。
setLeft と setX の名前を LMSetLeft と LMSetX に変更すると、衝突の可能性を大幅に減らすことができます。
これも、IDE のリファクタリング ツールを使用している限り、非常に簡単に変更できるはずです。