Code Smell 88 - Lazy Initialization
·Sep 29, 2021·
2 min read
Play this article
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.
Photo by Sam Solomon on Unsplash
We have to stop optimizing for programmers and start optimizing for users.
This article is part of the CodeSmell Series.