When I started object-oriented programming back in the early nineties using Smalltalk, and then on to C++ (yes, this was a backwards move, but required at the time) I always designed and coded my objects from the ''outside'' to the ''inside''.

ExtremeProgramming has a similar concept, called CodeUnitTestFirst.  A UnitTest in this context is simply a way of saying, "Does this interface make sense on this object?"  It gives the developer the perspective of the object's eventual ''user''; not of himself, who is trying to code the thing from ground zero.  A good by-product of UnitTest''''''s in XP is that they also exercise the functionality of each object's interface from a ''user's perspective.''

In today's world, where Java is the prevalent development language, one can see that many developers don't know about this technique.  You can spot objects that break this technique because their interfaces are klunky:  They aren't related to other objects that they may need to collaborate with, or they may have very simple interfaces that expose too much detail about their internals.

For instance, if I had an object, say Customer, that had a collection of Account objects, and I designed the Customer object to collect them via a Dictionary, I wouldn't provide a "getter" to the raw Dictionary.  This isn't designing from outside-in, it's designing from the inside-out.  I've made my job of implementing the object easier -- ''for now''.  But what happens when the "key" needed to lookup the Account object in the Dictionary becomes complex?  Then the user of the Customer object must know to new-up an AccountKey object.  This is a bad, and brittle, interface.  What I should do is ask for the key information (like the Strings or Integers needed) in my own wrapper interface at the Customer object level and handle the ugly nature of newing up an AccountKey and getting the Account for the user.

Designing from the outside-in is required if you are trying to follow ResponsibilityDrivenDesign.

Seems like common sense, but you'd be surprised how many objects I've seen that don't follow this simple rule.  Code your objects from the outside-in, and you'll begin to see powerful object-oriented systems emerge before you. -- JeffPanici