理論上、すべてのクラスに他のすべてのクラスが含まれていれば、どれくらい悪いですか？

Question

30クラスのiPhoneアプリを想像してみてください。すべてのクラスはお互いに対話しなければならないので、すべてのクラスには29の他のクラス+基礎フレームワークが含まれています。

クラスを組み込むときに何が起こっているのかを理解したいと思います。これは、アプリケーション内のそのクラスのメモリ内のサイズを複製しますか？ iPhoneのメモリ使用量とパフォーマンスには害がありますか？たぶん誰かがこれを細かく知っていて、説明することができます。

これは良いアーキテクチャではないことを忘れてください。これは、メモリとパフォーマンスに「含まれる」ものが何であるかについての疑問な質問です。

Answer 1

包含とインスタンス化には違いがあります。すべてのクラスが他のクラスをインスタンス化しようとすると、これは非常に悪いことです。

どこからクラスをインスタンス化できるようにファイルへの参照を提供するだけであれば、不具合を修正しようとすると悪いパスが唯一の問題になります。

たとえば、1つのファイル（またはクラス）の名前を変更すると、そのパスへの他の不正な参照29件を修正しなければなりません。

私が知っている限り、（少なくとも私がよく知っている言語で）ファイルを含めるだけで、パフォーマンスに悪影響はありません。

Answer 2

通常、インクルードとスコープのオブジェクト指向などは、プログラマのためのユーティリティに過ぎません。もしそうなら秩序の錯覚。マシンコードレベルでは、どこのプロセスの変数にもアクセスできます。プログラムのどこかで使用されているヘッダーをインクルードする必要があるのは、言語の作成者が現在考えていることを制限したり、重複などを捨てたり、コンパイラーがプログラムの「説明」が正しく機能します。

あなたは、あなたがそれに物事をリンクする場合にのみ、実行可能ファイルを大きくします。 Evernoobがヒントを得たように、インスタンスをたくさん作成した場合には、それを遅くするだけです。タイプや定義を他のクラスに「知らせる」ことで、実行時にパフォーマンスの問題は発生しませんが、通常はコンパイル時間が長くなります。

Answer 3

パフォーマンスヒットに遭遇する唯一のケースは、コンパイル時です。クラスのヘッダーにの代わりに#import "MyClass.h"を使用すると、MyClassへのインターフェイスが変更されたときに再コンパイルされます。これにより、コンパイル時間が少し増えますが、これは大規模なプロジェクトに追加される可能性があります。

EDIT（8/29/2009）：上記の答えで#includeを#importに変更しました。これは、ObjCでヘッダーの繰り返しが含まれないように使用されています。

Answer 4

一般的に依存関係を抑えようとすると、1つのクラスが変更されたときに大量のコードを変更する必要がなくなります。

多くのファイルを含めるだけで、必ずしも悪くはありません。ファイルを数百にするまでは、コンパイル時間は長くなりますが、それほど目立ちません。

頭に入れておくべきことは、ヘッダーからクラスファイルへのインクルードに違いがあることです。ヘッダーのクラス定義に、ヘッダーが含まれている場合、循環参照があり、クラス参照の1つを@classディレクティブで転送クラスとして宣言する必要があります。実際、標準では理論的にはヘッダーファイルでは "@class"、実装では "@import"を使用していますが、通常はヘッダーの#importも同様に動作するので、ややタイピングが少ないです。