File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Coarse grained v/s fine-grained objects

 
ankur rathi
Ranch Hand
Posts: 3830
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What are Coarse grained and fine-grained objects. Which one is recommended?

Thanks.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
ankur rathi
Ranch Hand
Posts: 3830
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3830
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic