Objective-Cのメソッドオーバーヘッドにより、「多数の小さなメソッド」の設計アプローチはお勧めできませんか？

Clean Codeの Bob Martinが推奨しているように、私は一般的に小さなメソッドを使用することを好みます。また、Objective-Cの内部についても十分に読んで、メッセージのディスパッチがどのように機能するかについて少なくともある程度理解しました（これについてはbbumsシリーズが特に有益です）。

時期尚早な最適化の懸念にもかかわらず、Objective-cがobjc_msgSendで実行するすべての作業が、実用的な観点から、Objective-Cプロジェクトには「多くの小さなメソッド」アプローチが不適切であるかどうかを知りたいと思います。

経験的な調査結果は特に歓迎します（多分私はいつか自分でテストをセットアップするでしょう）。大規模なObjective-Cプロジェクトを書いた人からの経験も素晴らしいでしょう。

明確化

質問の一般的な口調は意図的です。特定のアプリのパフォーマンスチューニングについては質問していません（そのため、SOではなくここで質問します）。Objective-Cの言語特性が特定の設計アプローチを妨げているかどうかについては詳しく説明しません。Appleや他の関係者（githubなど）から見たコードの多くは大きなメソッド（およびクラス）に向かう傾向があることに気付きましたが、これは言語のために忍び込んだバイアスかどうか疑問に思っています自体。もちろん、間違ったコードを読んでいた可能性があります。または、存在する場合は、傾向をもたらした技術的要因ではなく文化的要因である可能性があります。

（価値があることのために、私は現在Objective-Cを書いており、小さなメソッドを使用しています）

さらなるリクエスト

与えられた両方の答えに同意します。さらにもう1つ欲しいのは、誰かが素敵な短いメソッド（および小さなクラス）を使用する（願わくば実質的な）オープンソース（またはそうでなければ見える）のObjective-Cコードベースを指し示すことです。Objective-Cには、たとえばフィットネスソースと比較するものはまだありません。

オーバーヘッドが無視できるかどうかはわかりません。しかし、私は簡単に理解できるようにシステムを設計したいと思います 最初に保守ます。これは通常、小さく焦点を絞ったメソッドとクラスを意味します。これは、後続のコードの調整にも役立ちます（コードの保守性が向上したためです）。また、コードをプロファイルして、実際のボトルネックを見つけることも重要です。これは、メソッド呼び出しのオーバーヘッドとは関係がない場合もあります。オフプロセス操作（データベース、ネットワーク、ファイルシステムへの呼び出しなど）を実行する場合、これらはいずれにせよプログラムのランタイムを支配する傾向があります。

しかし、いつものように、走行距離は異なる場合があります...

コードの大部分は、いずれの場合もパフォーマンスに重要ではありませんアプリケーションため、メソッドのオーバーヘッドが他の言語に比べてかなり大きい場合でも、ほとんどの場所に多くの小さなメソッドを配置し、プロファイリングするメソッドのみをインラインにすることが最適なアプローチですパフォーマンスが重要であることが示されています。

もちろん、適切に最適化する方法を知らない人も多く、メソッドオーバーヘッドについて知っている人もいれば、グローバルな時期尚早な最適化の行為に従事している人もいますが、グループが大きな影響を与えるほど十分に大きいとは思いませんObjective-Cエコシステムについて。

大規模なメソッドとクラスは、プロファイラー、メソッドのオーバーヘッド、または適切な設計について何も知らないか気にせず、あらゆる言語で泥の大玉を生成する傾向がある大規模なグループの作業である可能性がはるかに高くなります。そして、はい、それらの人々の何人かは、主要なソフトウェア会社で有名なコードベースで働いています。