In Ruby, how does private_class_method :new force Salary objects through factory methods, and what can still create one without them?

## Why private alone does not work `Salary.new` is a call on the **class object**. The method that runs is `Class#new`, found through the class's singleton side. A bare `private` section, or `private :new`, only affects **instance methods** of `Salary`, so neither hides `Salary.new`. `Module#private_class_method` is the tool its own documentation names for this: it makes existing class methods private and is "often used to hide the default constructor `new`". ## The factory pattern ```ruby class Salary private_class_method :new def self.from_cents(cents) = new(cents) def self.from_units(units) = new(units * 100) def initialize(cents) raise ArgumentError, "negative salary" if cents.negative? @cents = cents end end Salary.from_units(50) # works Salary.new(5_000) # NoMethodError: private method 'new' called for class Salary ``` How each piece behaves: 1. **Inside class methods**, `new(cents)` has no explicit receiver, so the private method is allowed. `self.new(cents)` works as well, since a literal `self` receiver is allowed for private methods. 2. **Outside the class**, any `Salary.new(...)` raises `NoMethodError`. 3. **The return value** of `private_class_method` is the class itself, not the list of names. 4. **Subclasses** inherit the private `new`: `class Bonus < Salary; end; Bonus.new(1)` raises too, while `Bonus.from_cents(1)` returns a `Bonus` because `new` runs on `Bonus`. A subclass that wants a public constructor can call `public_class_method :new`. ## What still bypasses it | Route | Why it gets through | |---|---| | `Salary.allocate` | `Class#allocate` stays public and never runs `initialize` | | `Salary.send(:new, 1)` | `send` ignores visibility | | `salary.dup`, `salary.clone` | copying allocates a new object and copies state without calling `new` | | deserialization libraries | they typically allocate and fill objects without calling `new` | `Salary.public_send(:new, 1)` does **not** get through: `public_send` respects visibility and raises `NoMethodError`. ## What that means for design - **Put invariants in `initialize`.** Every `new` call runs it, whichever factory made the call, so a check there cannot be skipped by adding a new factory. Only paths that bypass `new`, such as `allocate`, copying and deserialization, skip it. - **Use private `new` to express intent**: "construct me through these named methods", for example because the unit of the argument is ambiguous (`from_cents` versus `from_units`) or because instances are cached. - **Do not treat it as security.** Anything with access to the process can reach `allocate` or `send`; the goal is to stop honest mistakes. - **Keep the factories few and named for what differs.** Several factories that all call `new` with the same arguments add names without adding meaning. ## Where interviewers push - **"Why not raise in `initialize` to block direct construction?"** Because factories call `new`, which calls `initialize`; `initialize` has no clean way to tell who called `new`. Visibility on `new` is the tool that distinguishes callers. - **"Does the factory need `send`?"** No. Inside a class method, `self` is the class, so a bare `new(...)` is an implicit-receiver call that private allows. - **"Can you undo it?"** Yes: `public_class_method :new` makes it public again, in the same class or a subclass. ## Related uses - **Instance caches**: a factory returns an existing object for a key instead of building a new one, which only works if nobody calls `new` directly. - **The standard library's `Singleton` module** makes both `new` and `allocate` private in the same way, so that only its `instance` method creates the object.