Yet another premature optimization pattern
TL;DR: Do not use lazy initialization. Use an object provider instead.
Surprising Side Effects
Fail Fast Violation
The Least Surprise Principle Violation
Transactional and Multi-threaded applications problems
- Inject Responsibilities with First Class Objects
@emails ||= 
@voice_mails ||= 
attr_reader :emails, :voice_mails
@emails = 
@voice_mails = 
#We can also inject a design pattern to externally deal
#with voice_mails so we can mock it in our tests
- Lazy initialization is a common pattern when used checking for a non-initialized variable. It should be straightforward to detect them.
- Premature Optimization
Singletons are another antipattern often combined with lazy initialization.
We must avoid premature optimizations. If we have real performance problems we should use a Proxy, Facade or more independent solution.
We have to stop optimizing for programmers and start optimizing for users.
This article is part of the CodeSmell Series.