This week's book giveaway is in the Artificial Intelligence and Machine Learning forum.
We're giving away four copies of Zero to AI - A non-technical, hype-free guide to prospering in the AI era and have Nicolò Valigi and Gianluca Mauro on-line!
See this thread for details.
Win a copy of Zero to AI - A non-technical, hype-free guide to prospering in the AI era this week in the Artificial Intelligence and Machine Learning forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Paul Clapham
  • Bear Bibeault
  • Jeanne Boyarsky
Sheriffs:
  • Ron McLeod
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Jj Roberts
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • salvin francis
  • Scott Selikoff
  • fred rosenberger

static persistence classes

 
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?
 
best scout
Posts: 1294
Scala IntelliJ IDE Java
  • 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
 
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
Posts: 1294
Scala IntelliJ IDE Java
  • 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
reply
    Bookmark Topic Watch Topic
  • New Topic