The cores of everyone's development efforts are classes. You've got down the basics of creating methods in your objects, you know how to keep them lightweight, and you're familiar with all of the syntax necessary to implement your ideas. However, what do you do when you have to think about how your object lives and breathes internally, not what it exposes to the world?
Internal vs. External
The way that an object exposes itself and the way that it behaves internally, can and should be different. Objects expose themselves in ways that makes them easy to use for the developer. They work in ways internally that hide all of the complexity from their external developer-users.
This is particularly true of lightweight objects, which behave externally like they are always fully populated while internally they only initialize the pieces of the object that they need. Take, for instance, a product object, which supports collection properties for related products, categories, attributes and vendors. Externally, the developer can access these properties at any time. Internally, the object populates the collections only when the user asks for them since each means a separate database hit. Internally, there are private fields that may or may not be initialized. Externally, the collection is always returned even if there is nothing in the collection.
The article continues at