In a conversation I had today, a great perspective/definition of components and objects came up. The ultimate author of this idea was Cat Johnson (so I guess I should give credit where credit is due), but I really like it.

Components are all about encapsulating a “process” where objects are about encapsulating the “data.”

So while a typical object would be a “credit card,” a good component would be a “credit card processing”.

OOP is all about … well, objects. The storage and management of data. But data objects are much more useful when you consider their relationships with other objects. This is why objects aren’t typically reusable. If you want to reuse an object, you need to grab all of the other objects that it has relations with.

A “component” on the other hand, is all about insulating the relationships behind interfaces. This way, you can reuse the service. Granted, these “actions” are also useless without the supporting objects, and so components tend to be larger than objects as it contains the necessary objects inside. However it does mean that you have a complete package.

This is probably why web services have potential to become reusable … they are services. You don’t think of a “weather web service,” you think of a “weather reporting web service.” They do a job without the client having to instantiate and coordinate a lot of supporting characters.

So, if you think about breaking your application done into its “jobs” and not into its characters, you end up with components that can be independent and reusable (see my previous definition discussion).

This method is not unlike your typical workplace environment. The “Org Chart” is really about responsibilities, jobs performed, and the interfaces between the objects that implement them. As long as the processes (interfaces) are in place, each worker is replaceable with a similarly skilled worker, and you get better coordination between the team members.