Update:

class Employee

def initialize

@ emails = []

end

end

class Employee

def emails

@ emails ||= []

end

end

Motivation

Mechanics

Move the initialization logic to the attribute getter.

Test

Example using ||=

class Employee

attr_reader : emails , : voice_mails



def initialize

@ emails = []

@ voice_mails = []

end

end

class Employee

def emails

@ emails ||= []

end



def voice_mails

@ voice_mails ||= []

end

end

Example using instance_variable_defined?

class Employee...

def initialize

@ assistant = Employee . find_by_boss_id ( self . id )

end

class Employee...

def assistant

@ assistant = Employee . find_by_boss_id ( self . id ) unless instance_variable_defined? : @assistant

@ assistant

end

This is probably going to be included inso I took another pass through it following all of your comments. Thanks for the feedback.Initialize an attribute on access instead of at construction time.==>The motivation for converting attributes to be lazily initialized is for code readability purposes. While the above example is trivial, when the Employee class has multiple attributes that need to be initialized the constructor will need to contain all the initialization logic. Classes that initialize instance variables in the constructor need to worry about both attributes and instance variables.The procedural behavior of initializing each attribute in a constructor is unnecessary and less maintainable than a class that deals exclusivey with attributes. Lazily Initialized Attributes can encapsulate all their initialization logic within the methods themselves.The code below is an Employee class with the email attribute initialized in the constructor.Moving to a Lazily Initialized Attribute generally means moving the initialization logic to the getter method and initializing on the first access.Using ||= for Lazily Initialized Attributes is a common idiom; however, this idiom falls down when nil or false are valid values for the attribute.In the above example it's not practical to use an ||= operator for a Lazily Initialized Attribute because the find_by_boss_id might return nil. In the case where nil is returned, each time the assistant attribute is accessed another database trip will occur. A superior solution is to use code similar to the example below that utilizes the instance_variable_defined? method that was introduced in ruby 1.8.6.