Que font attr_accessor, attr_reader et attr_writer ?

Question

Accepted Answer

Ce sont des méthodes Ruby qui **génèrent automatiquement les méthodes getter et/ou setter** pour les variables d'instance — éliminant le code passe-partout. Puisque les variables d'instance (`@name`) sont privées et non directement accessibles de l'extérieur, vous avez besoin de méthodes d'accès pour les lire/écrire, et `attr_*` les génère de manière concise.

## Le problème qu'elles résolvent

```ruby
# ❌ without attr_* — manually writing getters/setters (tedious boilerplate)
class Person
  def initialize(name)
    @name = name
  end
  def name           # manual getter
    @name
  end
  def name=(value)   # manual setter
    @name = value
  end
end
```

## Les trois générateurs d'accès

```ruby
class Person
  attr_reader :name      # generates a GETTER only (read-only): person.name
  attr_writer :email     # generates a SETTER only (write-only): person.email = ...
  attr_accessor :age     # generates BOTH getter and setter: person.age / person.age = ...

def initialize(name, age)
    @name = name
    @age = age
  end
end

person = Person.new("Ann", 30)
person.name        # "Ann" — reader
person.age = 31     # writer
person.age          # 31 — reader
person.name = "X"   # ❌ NoMethodError — name is read-only (attr_reader, no setter)
```

- **`attr_reader`** → getter uniquement (accès en lecture seule).
- **`attr_writer`** → setter uniquement (accès en écriture seule).
- **`attr_accessor`** → getter et setter (lecture-écriture).

Chacun prend des symboles nommant les variables d'instance et génère les méthodes correspondantes automatiquement — une ligne remplace plusieurs définitions de méthode manuelles.

## Choisir le bon (encapsulation)

```ruby
class BankAccount
  attr_reader :balance     # ✅ balance is readable but NOT directly settable (protect it)

def initialize
    @balance = 0
  end
  def deposit(amount)       # changes go through a controlled method, not a raw setter
    @balance += amount if amount > 0
  end
end
```

Choisir `attr_reader` (plutôt que `attr_accessor`) pour les champs qui ne devraient pas être définis arbitrairement de l'extérieur est une bonne encapsulation — n'exposer que l'accès que vous avez l'intention de fournir.

## Pourquoi c'est important

Comprendre `attr_accessor`/`attr_reader`/`attr_writer` est une connaissance Ruby fondamentale du quotidien, puisqu'ils apparaissent dans presque chaque classe Ruby.

La raison fondamentale de leur existence : les variables d'instance (`@name`) sont **privées et non directement accessibles** de l'extérieur d'un objet, donc vous avez besoin de méthodes d'accès pour les lire ou les écrire — et écrire manuellement ces getters/setters pour chaque attribut est du code passe-partout fastidieux.

Ces méthodes **génèrent les accesseurs automatiquement** (`attr_reader` pour la lecture seule, `attr_writer` pour l'écriture seule, `attr_accessor` pour les deux), remplaçant plusieurs définitions de méthode par une seule ligne concise — une caractéristique de l'élégance et de la concision de Ruby.

Comprendre ce que chacun génère et **choisir le bon** est aussi une question de bonne **encapsulation** : utiliser `attr_reader` (lecture seule) pour les champs qui ne devraient pas être arbitrairement modifiés de l'extérieur, et `attr_accessor` seulement où l'accès lecture-écriture est véritablement prévu, contrôle la manière dont l'état d'un objet est exposé (par exemple, rendre un solde bancaire lisible mais modifiable uniquement par des méthodes contrôlées).

Puisque ces accesseurs sont omniprésents dans les classes Ruby (et les modèles Rails), savoir comment ils fonctionnent, ce que chacun génère, et comment les choisir pour une bonne encapsulation est une connaissance essentielle et incontournable pour écrire et lire des classes Ruby — c'est l'une des premières choses que vous rencontrez lors de la définition de classes Ruby et reflète l'approche concise et expressive du langage face à un besoin courant (accès contrôlé à l'état d'un objet).