• Post Reply Bookmark Topic Watch Topic
  • New Topic

Object Granularity  RSS feed

 
krish chandru
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
All,
In my project there are numerous objects. Most of them are composition of 3-4 data fields with accessor methods for them and couple of action methods. I am worried as the number of these objects grow in size when i think of enhancing the reusability of the objects. I manage to have certain of them as static.
I am just worried if the number of object instantiation is in a way inversely propotional to the performance of the system. What is the concept behind this object instantiation and performance ?
Note:
I dont feel any performance degradation though !
Any help is greatly appreciated !
Thnaks
kaycee
 
David Weitzman
Ranch Hand
Posts: 1365
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First: If it ain't broke, don't fix it! It sounds like it ain't broke.
Object creation is indeed one of the slower operations in Java, and when the garbage collecter runs to find orphaned objects it freezes the entire application temporarily. But "slower" does not mean slow -- it works well enough for most people most of the time.
In some cases rapid object allocation and dereferencing can be a performance problem. If you make and destroy a lot of objects in a short period of time, the garbage collector can run too frequently and cause annoying delays. Often that can be fixed with object pooling (reusing existing instances instead of allocating new ones).
Another problem that might crop up is if you want to keep a lot of object records in memory but just can't fit them as complex objects. There's a certain memory overhead of storing something in object form. The best solution in that case is to just get the records out of memory (with a database, for instance). Failing that you may need to replace the objects with clever use of raw data or simple objects in arrays.
But unless you can prove that the use of objects is noticably affecting the performance of your application, don't do anything.
 
krish chandru
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David,
Great help. Thanks.
The application is going smooth and no actual performance threat in my JVM. I would like to know if there is any suggestion regarding, how granular a class may be. Though the objects I use are finely granular, I think if I might have grouped couple of fine pieces of objects into one. Let me illustrate an example, say I have a class called book, Book has pages and cover.
So I decompose this to 3 objects. Instead, I might have had a class called book, which will contain predefined type of paper and predefined kind of cover.
I feel this approach would not be very much enhanceable. Also there will be lesser object instantiation. What is the trade off between these two.
I may be conceptually wrong or even missing some basics. Just curious to know things.
kaycee
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would tend to use the smaller classes, as they are
- easier to understand
- easier to reuse
- easier to be substituted by different implementations
BTW, I am curious: How many are "numerous"?
 
krish chandru
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ilja ,
Thanks for your comments.
I have around some 70 classes out of which nearly fifteen are helper classes. Is that numerous or not ?
kaycee
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
70 classes would be a rather small system, for me. I am currently working on projects with up to a thousand classes, and those are in fact too *few*. We are reducing the actual system size (lines of code) *and* complexity by splitting up single classes into several ones (sometimes up to twenty) and making informed use of polymorphism.
Wether 70 is a good number of classes for your system depends on what the system is doing, of course. The important part is that every class has a tightly defined responsibility. In my experience it most often results in classes with not more than a handfull of methods only a few lines long, operating on a handfull of fields.
I don't understand what you mean by "helper classes", though - can you please elaborate?
 
krish chandru
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A System with thousands of classes sounds really good.

I don't understand what you mean by "helper classes", though - can you please elaborate?

Definitely yes - We have few application specific numeric calculations, for which we use some specific set of formulae. We implement these though static methods. There are some fifteen of such classes with related methods. These are pretty straight forward classes not needing any instantiation.
I do understand after revisiting my architecture, that my architecture though performing well, doesn't leverage the need to accomodate more than one output device. After hearing the number of classes that you ppl use, I boldly step into breaking the system fewer classes more to accomodate this feature.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!