How bad is it, in theory, if every class would include every other class?

Question

Imagine an iPhone app with 30 classes. Every class has to interact with every other, so every class includes 29 other classes + foundation framework.

I want to understand what's exactly happening when including a class. Does this duplicate the size in memory for that class in the app? Is it harmful to memory footprint and performance on the iPhone? Maybe someone knows this in detail and can explain.

Please miss that this would not be a good architecture. It's a hypothetic question about what "include" does to memory and performance.

Answer 1

There is a difference between including and instantiating. If every class attempts to instantiate the other, then yes this is very bad.

Although, if you are simply providing a reference to the file so that any class can be instantiated from anywhere, the only issue you'll likely run into is that of bad paths if you try to change stuff around.

changing the name of one file (or class), for example, means you now have to go and rectify 29 other bad references to that path.

As far as I'm aware, simply including the file (at least in languages I'm familiar with) will not adversely affect your performance.

Answer 2

Usually the including and scoping, object orientation etc is only a utility for the programmer. An illusion of order if you will. Down at the machine code level, you can access any variable of your process everywhere. That you have to include headers that are used somewhere else in your program is only a way that language creators use to limit the things you currently have to think about, throw out duplicates etc. and that the compiler can give you help in verifying that your "description" of the program works right.

You only make your executable bigger if you link stuff into it. You only make it slower, as Evernoob hinted at, if you produce lots of instances etc. Just to make types and definitions "known" to other classes should not cause any performance issues at runtime, but it usually will increase compile time.

Answer 3

The only case where you might run into a performance hit is at compile time. By using #import "MyClass.h" instead of @class MyClass in the header for a class, it will be recompiled when the interface to MyClass changes. This will add a little to your total compile time, which may add up over a large project.

EDIT (8/29/2009): I changed #include to #import in the above answer, as that's used in ObjC to prevent repeated includes of headers.

Answer 4

In general trying to keep dependancies down is more about not having to change a ton of code when one class changes.

Simply including lots of files, it not necessarily bad - all it would do is increase compile time but the increase would not be really noticeable until you got to hundreds of files (if that).

Something else to keep in mind is that there's a difference between including from a header vs. a class file. If you include a class definition from a header that in turn includes a header you are in, you have a circular reference and you'll have to declare one of the class references as a forwarded class with the @class directive. In fact the standard is theoretically to use "@class" in the header file and "@import" in the implementation, but usually you don't run into classes having references for each other so #import in the header works just as well, and is a little less typing.