[RUBY] À propos des variables d'instance et attr

Aperçu

Même si c'est une fonction pratique, il peut y avoir des inconvénients.

Par conséquent, l'utilisateur doit être en mesure de juger de l'équilibre entre les avantages et les inconvénients et de le mettre en œuvre de manière appropriée. J'ai pensé, je l'ai résumé dans un article.

Dans certains cas, la difficulté de la maintenance l'emporte en fait sur la difficulté, et est-ce encore nécessaire? J'espère qu'il vous sera utile d'envisager

Que se passe-t-il si vous utilisez d'abord attr_ *?

ʻAttr_reader: name` définit la méthode getter avec le nom de l'argument

def name
  @name
end

ʻAttr_writer: name` définit la méthode setter avec le nom de l'argument

def name=(val)
  @name = val
end

ʻAttr_accessor: name` est une méthode composite de lecture et d'écriture

Normalement, les variables d'instance accessibles par @ hoge à l'intérieur de l'instance sont publiques et la méthode est définie, de sorte que la valeur de la variable d'instance peut être touchée de l'extérieur.

À ce stade, il est également possible de définir une méthode de manière privée en utilisant private.

private
attr_reader :hoge

À propos des avantages et des inconvénients

mérite

Appel de l'extérieur

Il peut être utilisé de l'extérieur car il est coupé comme la méthode «publique», ce qui est le but initial.

Peut aussi être privé

Comme vous le savez tous ici.

Facilité de réparation

class Hoge
  private
  attr_accessor :hoge

  def initialize(hoge:)
    @hoge = hoge
  end

  def connect
    Service.call(hoge: hoge) # <-Ici
  end
end

Quand il est mis en œuvre comme ça

def hoge
  @hoge + 1
end

Si vous devez le réparer de cette manière, vous pouvez le remplacer pour le rendre plus facile à réparer.

Démérite

Connaissance de la portée

Vous devez penser correctement à «public» ou «privé», etc.

Définition de la méthode

La définition par inadvertance d'une méthode peut entraîner des noms de méthodes contradictoires

lisibilité

Si vous pouvez le remplacer, la méthode est-elle remplacée? Besoin de vérifier => La lisibilité est réduite

Exemple

class Hoge
  include Hoge::XXXable
  include Hoge::ZZZable

  private
  attr_accessor :hoge

  def initialize(hoge:)
    @hoge = hoge
  end

  def connect
    Service.call(param: param)
  end
end

module Hoge::XXXable
  include ::YYYable
  def param
    {
      hoge: hoge # <-Ici
    }
  end
end

Pour le module prérequis (module de découpe) inclus dans la classe cible de cette manière Il fait simplement référence à une variable d'instance mais peut être un appel de méthode

C'est

module Hoge::XXXable
  include ::YYYable
  def param
    {
      hoge: @hoge # <-Ici
    }
  end
end

Si c'est le cas, vous pouvez facilement comprendre que "la variable d'instance de la classe à inclure et à charger est définie" simplement en regardant la source dans le module.

Je comprends si cela signifie que je ne veux pas écrire de variables d'instance qui entrent en contact direct avec d'autres classes ou modules.

Cependant, comme il s'agit de la méthode getter d'attr, si vous regardez simplement le module XXXable, où est défini le hoge? Je ne comprends pas. Alors quelque part en dessous? Le travail de recherche se produira.

Est-il défini dans "XXXable"? --Dans le module inclus ou étendu par XXXable --Classes et modules qui incluent XXXable
Le module chargé par la classe ou le module qui inclut XXXable

Conclusion

** Facile à entretenir ** mentionné dans le mérite est applicable dans le sens où il est facile à écraser. Si le besoin est imprévisible à ce stade, n'est-il pas ** difficile à maintenir **?

N'est-ce pas un cas où ces inconvénients deviennent plus grands lors de son utilisation? Je vais réfléchir à l'opportunité de l'utiliser en réfléchissant à nouveau J'aimerais écrire un meilleur programme

[RUBY] À propos des variables d'instance et attr_ *