David Bau has an interesting post on when one should choose Encapsulation or Representation. http://davidbau.com/archives/2003/11/12/encapsulation_or_representation.....

Use encapsulation within a subsystem. Use representation between subsystems.

Encapsulation creates a language API binding. This is the least
flexible option when trying to integrate between subsystems.
CORBA, RMI, RPC, etc have all pretty much failed for system
integration for this reason.

For example, i want to use Perforce via a programmatic interface.
They have a C++ API that runs on platform X. I use perl and i am
on platform Y. Within Perforce they should use a carefully
crafted encapsulation. If they had used SOAP or simple HTTP
at the subsystem boundry i would be set. These are available to me
in every language on every platform.

Encapsulation makes for a great internal program architecture.
Representation between subsystems makes for great accessibility
from any language and platform.

Perforce has a command line program called p4 which people often use
to make wrappers around perforce. The problem is this is neither encapsulation
or representation. The output must be screen scraped because it is meant
for CLI display. This is a far cry from having a well defined schema with
specific fields and values. With perl's regular expressions screen scraping
isn't horrible, but it is still crude and error prone.