January 24, 2012

Supporting short lived objects

While working on some projects with different environments and behaviors, I started liking the notion of short-lived objects. Besides, I read a lot in several threads from StackOverflow > http://stackoverflow.com/questions/631919/short-lived-objects.
Kill them all!


I like this kind of objects because they are easy to control, debug, update, delete. The notion of having an long living object is state, but to keep that state among several instances and requests can be a real hell if you don't control it properly.

And as you may guess, concurrency is one of the things I don't like to deal with, I prefer to leave it to a framework or third-party concurrency manager.

Benefits:
  • Easy to control
  • Easy to code
  • Easy to test
  • Challenges your design skills
  • Avoids singleton all over the place
  • It enhances performance 
Drawbacks:
  • If you don't control them, you can have an big object pool
  • You have to take care of references and garbage collection
  • If your design is bad, your objects will be bad as well.