In Ruby, how does a @@class variable differ from a class-level @instance variable when Shape has subclasses such as Circle and Square?

## Two kinds of class-level state Ruby has two ways to keep data at the level of a class rather than one object: - **Class variables**, written `@@name`. They belong to a class **and its whole subclass tree**. - **Class-level instance variables**, written `@name` but set where `self` is the class: in the class body or inside `def self.` methods. They belong to **one class object**. The second kind works because a class is itself an object, and every object can have instance variables. Nothing special happens; the object just happens to be `Shape`. ## Counting shapes both ways ```ruby class Shape @@total = 0 def self.count = @count || 0 def self.total = @@total def self.track! @count = count + 1 @@total += 1 end def initialize self.class.track! end end class Circle < Shape; end class Square < Shape; end Circle.new; Circle.new; Square.new Circle.count # => 2 Square.count # => 1 Shape.count # => 0 Shape.total # => 3 Circle.total # => 3 ``` What happened: 1. `Circle.new` calls `self.class.track!`, and `self.class` is `Circle`, so `track!` runs with `self` = `Circle`. 2. `@count` there is **Circle's** instance variable. Square's and Shape's are different variables. 3. `@@total` is looked up through the class tree, finds the one defined in `Shape`, and every class increments that single slot. ## Side by side | | `@@total` class variable | class-level `@count` | |---|---|---| | Owned by | the class that first assigns it | one class object | | Seen by subclasses | yes, the same slot | no, each class has its own | | Seen by instance methods | yes, as `@@total` | no; `@count` there is the object's | | Unset read | `NameError`: uninitialized class variable | `nil` | | Subclass write | changes the parent's value too | changes only the subclass | Two rows deserve attention: - An **unset** class variable raises `NameError`, while an unset instance variable of any object, including a class, reads `nil`. That is why `self.count` uses `@count || 0`. - A **subclass write** to `@@total` does not create a Circle-only copy when Shape already has `@@total`; it updates Shape's. If no ancestor has the variable yet, the assignment creates it in the class that runs it. ## The trap people fall into A common mistake is to reach for `@@count` to count instances "per class": ```ruby class Shape @@count = 0 def initialize @@count += 1 end def self.count = @@count end ``` Now `Circle.count`, `Square.count` and `Shape.count` all return the same total, because there is only one `@@count`. The per-class version needs class-level `@count`, as in the first example. The reverse mistake is expecting a class-level `@setting` to reach subclasses. `Circle` sees `nil` unless it sets its own or a reader falls back to `superclass`. ## Choosing between them 1. Ask **who should see a change**. If a write from `Circle` must be visible to `Shape` and `Square`, the value is tree-wide and `@@` matches that; otherwise use a class-level `@ivar`. 2. Ask **what a subclass should read by default**. A class-level `@ivar` gives `nil` in a subclass, so decide whether the reader falls back to `superclass` or the subclass must set its own value. 3. Expose either kind through `def self.` readers rather than touching the variable from many places; changing the storage later then means editing one method. Most per-class counters, registries and settings end up as class-level `@ivars`, which is why many teams treat `@@` as the exception that needs a reason. ## Why interviewers ask it It is the standard way to test whether a candidate understands that classes are objects. Someone who explains both variables in terms of **which object owns the slot** (the whole tree versus one class object) can predict every row in the table without memorising it.