• Post Reply Bookmark Topic Watch Topic
  • New Topic

static persistence classes  RSS feed

 
Tristan Van Poucke
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

I have a lot of persistence classes without private or public variables, ...
The methods only differ with the parameters passed to them.

So I thought I could save some memory making them all static methods.

Is this the way to go, or should I make them singletons or something?
 
Marco Ehrentreich
best scout
Bartender
Posts: 1294
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tristan,

static methods or variables are (usually) not a good idea. They have some disadvantages and you lose advanced object oriented core features like inheritance or polymorphism. Moreover modern JVMs and garbage collectors are even optimized for object creation and collection (as far as I know). So concepts like object pooling to save memory or gain performance are not necessary any longer. Optimization should be avoided in general if there's no real evidence of a performance or memory problem!

Marco
 
Sebastian Janisch
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Marco Ehrentreich wrote:\Optimization should be avoided in general if there's no real evidence of a performance or memory problem!


Good point. There are two principles for optimization

1. Don't do it.
2. Only do it when you REALLY know what you're doint.

I think that speaks for itself.
 
Tristan Van Poucke
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Okay

I have no real performance issues, so I will leave it as it is.

Thanks for clearing that up for me.
 
Marco Ehrentreich
best scout
Bartender
Posts: 1294
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's a lot easier this way. First make it right and IF you know there's a memory or performance bottleneck and you know where exactly it is and you are sure that an optimization would help, then you can just optimize where really necessary. But for most applications it's more desirable to make them easy to understand, maintain and extend because there will never be a real problem at runtime.

Btw. there are other deprecated "best practices" like setting reference variables to null to "help" the garbage collectors. In fact there are some online articles which explain that it's usually just counterproductive to try to help the garbage collector this way. So be careful if you read about such optimization techniques. They could be outdated or just plain wrong. The problem is similar for the singleton pattern you mentioned above. We already discussed this here in a lot of posts and there are plenty of articles which show why this pattern today should be considered as a bad practice.

Marco
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!