Linking of Classes

  Because methods are not usually called directly, but invoked via a message
  at runtime, it is not possible for the linker to automatically link in
  only the methods required by a particular application. This is why all the
  methods for a class are usually defined in the same module as the class
  specification, so that all the methods of a class are linked in along with
  the class function, whether they are used in the linked application or
  not.

  This is an inevitable consequence of late binding in an object oriented
  system. Even (mostly) early bound C++ is not immune to this effect.

  Those who have experienced memory problems with Clipper in the past may
  shudder at the idea of linking in procedures which are not necessary at
  runtime, but it is not as bad as it sounds. The code overlaying system in
  Clipper 5.x was designed with such systems in mind. In fact, the ceiling
  for program size under Clipper 5.x is likely to be related to the size of
  the symbol table and use of fixed memory rather than actual code size. The
  fact that Clipper linkers can perform symbol table compaction also helps
  in this area.

  Object-oriented systems, especially in the Clipper world, also often tend
  to be more data driven than their procedural counterparts, resulting in
  smaller code sizes.

  So, in general, one should not try to optimize linkage of classes by using
  external methods, since this results in what amounts to manual
  linking.

  However, a good design practice which should be followed in any case, is
  to keep individual classes small. Large, single, 'do-everything' classes
  should be avoided. Functionality should be added by inheritance. When
  choosing which class to use for a particular purpose, in most cases it
  should be possible to choose a class at the correct level of the
  inheritance tree such that a minimum of unnecessary methods are linked in.