Object Maturity Model

I once had an idea for a short story. In the story a man dies and discovers that reincarnation is real. He comes back as a monkey, lives that life and dies again. Over time he discovers that he comes back as a "lower" form on the evolutionary ladder each time, with progressively less control over his environment. He finally comes back as a microbe and learns that the deepest appreciation of life comes from relinquishing control and accepting your environment.

Over time, I've become more and more leery of linear rankings. I'm also the kind of guy who tends to see commonality whether it is there or not. So here is a haphazardly ordered list of what I think that it takes for an object to be mature. The direction of the ordering is up to you. I use the word object in the broadest software sense.. a run-time instance, a collection of components, an agent. Key in all of these things is the idea that maturity relates to interaction with the environment.

• Encapsulates state; allows no direct data access
• Cleans up after itself
• Understands polymorphic messages
• Users only have to know a particular role of the object, not its full type
• Provides enough run-time information so that users can learn its protocol
• Comes with all its dependencies
• Able to save itself to an arbitrary persistent store
• Can initiate actions; encapsulates its own thread of control

Notice how some of these things: persistence, garbage collection, and protocol information are often handled by users of objects (development environments, language facilities etc.) removing responsibility from the objects themselves. In some languages, many of these things come for free. No object is an island, but it is kind of neat to think about these dimensions of autonomy. Just how autonomous does an object need to be?

-- MichaelFeathers

Sounds like a COM or CORBA or EJB object to me.

DildarMarhas