wood burning stoves*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Coarse grained v/s fine-grained objects Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Coarse grained v/s fine-grained objects" Watch "Coarse grained v/s fine-grained objects" New topic
Author

Coarse grained v/s fine-grained objects

ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
What are Coarse grained and fine-grained objects. Which one is recommended?

Thanks.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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
ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
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.



Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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?
ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
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 ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Coarse grained v/s fine-grained objects
 
Similar Threads
Croase-graind & fine-grained
Coarse-grained Objects
FIne Grained and Coarse Grained Objects
FineGrained Objects vs Coarse Grained Object
coarse grained and fine grained