I see this kind of granularity discussion usually in services and APIs. Coarse grained means a single call will do more work, fine grained means it might take several calls to get the same work done. Coarse grained is often better in distributed systems because calls between distributed components can be expensive and time consuming. Fine grained might be better in a very flexible system because clients could invent new combinations of calls to do new tasks.
Does that sound like it fits the question?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Oct 11, 2004
Thanks Stan for your input.
May be I am wrong but what I was thinking, coarse object means a *big* object, that has much responsibility. For example, suppose we are designing a system and we have identified logical entities (business domain objects) (I am not sure, it is right term or not) and now we want to come up with java classes corresponding to those. So should we try to map one entity to one java class (coarse object) or try that one entity should include many classes (each one will be fine object)...
Hope my point is clear.
Please comments. Thanks.
Joined: Jan 29, 2003
There are a lot of reasons to favor relatively small objects with crystal clear behavior and responsibility. The theory stretches back to the 70s with information hiding, low coupling and high cohesion. The practice pays off every day.
Larger objects that gather up more responsibility, behavior and data become harder and harder to develop, test, modify, reuse, read, deploy, etc.
There are some patterns like Facade that put large grained interfaces in front of small grained objects to protect clients of a service from having to understand all the tricky bits within.
Fine grained objects often appear in rich domain models with lots of interesting behavior and well hidden data. In architectures like stateless web servers you can wind up with an Anemic Domain Model that looks good this way at first glance, but turns out to do nothing but push data around.
Any of that help?
Joined: Oct 11, 2004
Yes Stan. Thanks. May be I will ask some more questions on this after reading some information. [ November 18, 2005: Message edited by: rathi ji ]