Class variables (@@) and their dangers in Ruby - Step-by-Step Execution

Concept Flow - Class variables (@@) and their dangers

Define class with @@var

↓

Create instance 1

↓

Modify @@var via instance 1

↓

Create instance 2

↓

Access @@var via instance 2

↓

Observe shared @@var value

↓

Potential unexpected shared state

↓

END

Class variables (@@) are shared across all instances and subclasses, so changing them in one place affects all others, which can cause unexpected behavior.

Execution Sample

Ruby

class MyClass
  @@count = 0
  def increment
    @@count += 1
  end
  def count
    @@count
  end
end
obj1 = MyClass.new
obj1.increment
obj2 = MyClass.new
obj2.count

This code shows how @@count is shared between obj1 and obj2, so incrementing in obj1 affects obj2's count.

Execution Table

Step	Action	@@count Value	Instance	Output
1	Define class MyClass with @@count = 0	0	none	none
2	Create obj1 = MyClass.new	0	obj1	none
3	obj1.increment called: @@count += 1	1	obj1	none
4	Create obj2 = MyClass.new	1	obj2	none
5	obj2.count called: returns @@count	1	obj2	1
6	End of execution	1	obj1, obj2	1

💡 @@count is shared, so after increment by obj1, obj2 sees updated value 1

Variable Tracker

Variable	Start	After Step 3	After Step 5	Final
@@count	0	1	1	1

Key Moments - 3 Insights

Why does obj2.count return 1 even though we never called increment on obj2?

Because @@count is a class variable shared by all instances, so when obj1 increments it, obj2 sees the updated value (see execution_table step 3 and 5).

What happens if a subclass also modifies @@count?

The subclass shares the same @@count variable, so changes affect the parent class and all instances, which can cause unexpected side effects.

Why can using @@ variables be dangerous in larger programs?

Because they are shared across the whole class hierarchy, accidental changes in one place can affect unrelated parts, making bugs hard to find.

Visual Quiz - 3 Questions

Look at the execution table, what is the value of @@count after obj1.increment is called?

A 1

B 0

C 2

D undefined

💡 Hint

Check execution_table row 3 where obj1.increment updates @@count

At which step does obj2.count return the updated @@count value?

A Step 2

B Step 5

C Step 3

D Step 4

💡 Hint

Look at execution_table row 5 where obj2.count is called and output is shown

If we create a subclass and increment @@count there, what happens to the value seen by obj1?

A It stays the same as before

B It resets to zero

C It increases because @@count is shared

D It becomes nil

💡 Hint

Remember @@count is shared across subclasses as explained in key_moments

Concept Snapshot

Class variables (@@) belong to the class and are shared by all instances and subclasses.
Changing @@var in one instance affects all others.
This shared state can cause unexpected bugs.
Use with caution or prefer class instance variables or constants instead.

Full Transcript

This visual execution shows how Ruby class variables (@@) work. We define a class with @@count set to 0. When we create obj1 and call increment, @@count increases to 1. Creating obj2 and calling count returns 1 because @@count is shared. This means all instances see the same @@count value. This shared behavior can cause unexpected results if subclasses or other instances modify @@count. Beginners often get confused why changes in one instance affect others. The key is that @@ variables belong to the class itself, not individual objects. This example helps visualize the shared state and why it can be dangerous in larger programs.

Practice

1. What is a key characteristic of Ruby class variables (@@)?

easy

A. They are unique to each instance of a class.

B. They are shared among a class and all its subclasses.

C. They are only accessible inside instance methods.

D. They behave like local variables inside methods.

Solution

1. Step 1: Understand class variable scope

   Class variables (@@) are shared across a class and all its subclasses, meaning they hold the same value for all related classes.

2. Step 2: Compare with other variable types

   Instance variables are unique per object, local variables are method-specific, so they don't share data like class variables do.

3. Final Answer:

   They are shared among a class and all its subclasses. -> Option B

4. Quick Check:

   Class variables share data across class hierarchy [OK]

Hint: Remember @@ means shared across class and subclasses [OK]

Common Mistakes:

• Confusing class variables with instance variables
• Thinking @@ variables are local to instances
• Assuming @@ variables are private to one class

2. Which of the following is the correct syntax to define and use a class variable in Ruby?

easy

A. class MyClass
@@count = 0
end

B. class MyClass
@count = 0
end

C. class MyClass
$count = 0
end

D. class MyClass
count = 0
end

Solution

1. Step 1: Identify class variable syntax

   Class variables start with @@, so @@count = 0 is correct for defining a class variable.

2. Step 2: Differentiate other variable types

   @count is an instance variable, $count is a global variable, and count alone is a local variable.

3. Final Answer:

   class MyClass @@count = 0 end -> Option A

4. Quick Check:

   Class variable syntax uses @@ [OK]

Hint: Class variables always start with @@ [OK]

Common Mistakes:

• Using @ instead of @@ for class variables
• Confusing global variables ($) with class variables
• Defining variables without any prefix

3. What will be the output of the following Ruby code?

class Parent
  @@value = 1
  def self.value
    @@value
  end
  def self.value=(v)
    @@value = v
  end
end

class Child < Parent
end

Parent.value = 5
puts Child.value

medium

A. 5

B. Error

C. nil

D. 1

Solution

1. Step 1: Understand class variable sharing

   The class variable @@value is shared between Parent and Child classes.

2. Step 2: Trace the assignment and output

   Setting Parent.value = 5 changes @@value to 5 for both classes. So, Child.value returns 5.

3. Final Answer:

   5 -> Option A

4. Quick Check:

   Class variables shared, so Child.value = 5 [OK]

Hint: Class variables share values across subclasses [OK]

Common Mistakes:

• Assuming Child has its own separate @@value
• Expecting default value 1 after change
• Confusing class variables with instance variables

4. Identify the problem in this Ruby code using class variables:

class A
  @@count = 0
  def initialize
    @@count += 1
  end
  def self.count
    @@count
  end
end

class B < A
  def initialize
    @@count += 10
  end
end

A.new
B.new
puts A.count

medium

A. The code has a syntax error in class B definition.

B. The class variable @@count is not initialized properly.

C. The class variable @@count is shared and modified differently causing unexpected count.

D. The method self.count is missing a return statement.

Solution

1. Step 1: Analyze class variable usage in inheritance

   Both classes A and B share the same @@count. A#initialize adds 1, B#initialize adds 10.

2. Step 2: Understand the effect on count

   Creating A.new adds 1, then B.new adds 10, so total @@count becomes 11, which may be unexpected if counting instances separately.

3. Final Answer:

   The class variable @@count is shared and modified differently causing unexpected count. -> Option C

4. Quick Check:

   Shared @@count causes tricky bugs [OK]

Hint: Shared @@ variables cause unexpected cross-class changes [OK]

Common Mistakes:

• Thinking @@count is separate per class
• Ignoring inheritance effect on @@ variables
• Assuming initialize methods don't affect shared vars

5. You want to track the number of instances created separately for two subclasses without interference. Which approach avoids the dangers of class variables (@@)?

hard

A. Use a local variable inside the initialize method to count instances.

B. Use a global variable ($count) shared by all classes.

C. Use class variables (@@count) but reset them in each subclass initialize.

D. Use class instance variables (@count) in each subclass instead of @@count.

Solution

1. Step 1: Understand the problem with class variables

   Class variables (@@count) are shared across subclasses, causing counts to mix and produce wrong totals.

2. Step 2: Use class instance variables for separate counts

   Class instance variables (@count) belong to each class separately, so each subclass can track its own count safely.

3. Final Answer:

   Use class instance variables (@count) in each subclass instead of @@count. -> Option D

4. Quick Check:

   Class instance vars avoid shared @@ dangers [OK]

Hint: Use @count per class to avoid shared @@count bugs [OK]

Common Mistakes:

• Using global variables which mix counts globally
• Trying to reset @@count which is error-prone
• Using local variables which don't persist counts