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
class Employee def emails @emails ||=  end def voice_mails @voice_mails ||=  end end
class Employee attr_reader :emails, :voice_mails def initialize @emails =  @voice_mails =  end end #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.