Code Smell 88 - Lazy Initialization

Code Smell 88 - Lazy Initialization

Subscribe to my newsletter and never miss my upcoming articles

Listen to this article

Yet another premature optimization pattern

TL;DR: Do not use lazy initialization. Use an object provider instead.

Problems

  • Surprising Side Effects

  • Premature Optimization

  • Fail Fast Violation

  • Implementative Coupling

  • The Least Surprise Principle Violation

  • Null Usage

  • Mutability

  • Transactional and Multi-threaded applications problems

  • Debugging Problems

Solutions

  1. Inject Responsibilities with First Class Objects

Sample Code

Wrong

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

Detection

  • Lazy initialization is a common pattern when used checking for a non-initialized variable. It should be straightforward to detect them.

Tags

  • Premature Optimization

Conclusion

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.

Relations

More Info

-Martin Fowler

Credits

Photo by Sam Solomon on Unsplash


We have to stop optimizing for programmers and start optimizing for users.

Jeff Atwood


This article is part of the CodeSmell Series.

 
Share this