Drupal 7 introduces a code registry - an inventory of all classes and interfaces for all enabled modules and Drupal's core files. The registry stores the path to the file that a given class or interface is defined in, and loads the file when necessary.
The registry loads classes and interfaces on demand, via php's built in class autoloading mechanism. This will cut down on the amount of code loaded per request, and reduce Drupal's memory footprint.
The only file unconditionally loaded by Drupal for a given module is
module_name.module. Any code that must always be available without using the registry should be put in this file.
Include classes and interfaces by listing them with the files property in your .info file. See https://www.drupal.org/node/542202#files
The registry is rebuilt when modules are enabled or disabled in order to incorporate new code or remove code from disabled modules. If you are developing new code with classes, make sure to rebuild the registry regularly so that new resources are incorporated. (Clearing all caches or calling registry_rebuild() directly both will do this.) Rebuilding an existing registry to incorporate new changes is not that expensive, as the registry will not reparse files that have the same path and modification time as the last build.
Under certain conditions a stale file registry can lead to errors that block access to a site. The Registry rebuild project provides tools to help address this problem.
Note Files that do not contain classes and interfaces that might be put into use at any time by your module file do not need to be listed with the files property in your .info file. Instead, such code can continue to be loaded when you need it, such as through the hook_menu()'s file property. If your module introduces hooks of its own, consider implementing hook_hook_info() to allow other modules' hook implementations to be autoloaded.