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.

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.

Object Calisthenics

Yet again I come here to share something learned from very smart people. Initially when I saw these rules my head exploded. Even though they are reasonable rules, they break the traditional non-object-oriented I've been doing for a while.

1. One level of indentation per method
2. No else keyword
3. Wrap all primitives and strings
4. Use only one dot per line
5. Don’t abbreviate names but keep them short
6. Keep all entities small
7. No more than two instance variables per class
8. Use first-class collections
9. Don’t use any getters/setters or properties

I'm still trying to wrap a prototype project around them, and the partial results are astonishing.

Sources

• Pablo Azero
• http://schneide.wordpress.com/tag/object-oriented/