Quand utiliser des classes imbriquées et des classes imbriquées dans des modules?

Je suis assez familier avec l'utilisation des sous-classes et des modules, mais plus récemment, j'ai vu des classes imbriquées comme celle-ci:

class Foo
  class Bar
    # do some useful things
  end
end

Ainsi que des classes imbriquées dans des modules comme ceci:

module Baz
  class Quux
    # more code
  end
end

Soit la documentation et les articles sont rares, soit je ne suis pas suffisamment informé sur le sujet pour chercher les bons termes de recherche, mais je n'arrive pas à trouver beaucoup d'informations sur le sujet.

Quelqu'un pourrait-il fournir des exemples ou des liens vers des articles expliquant pourquoi / quand ces techniques seraient utilisées?

D'autres langages OOP ont des classes internes qui ne peuvent pas être instanciées sans être liées à une classe de niveau supérieur. Par exemple, en Java,

class Car {
    class Wheel { }
}

seules les méthodes de la Carclasse peuvent créer des Wheels.

Ruby n'a pas ce comportement.

En rubis,

class Car
  class Wheel
  end
end

diffère de

class Car
end

class Wheel
end

seulement au nom de la classe Wheelvs Car::Wheel.. Cette différence de nom peut rendre explicite aux programmeurs que la Car::Wheelclasse ne peut représenter qu'une roue de voiture, par opposition à une roue générale. L'imbrication des définitions de classe dans Ruby est une question de préférence, mais elle sert un objectif en ce sens qu'elle applique plus fortement un contrat entre les deux classes et, ce faisant, transmet plus d'informations sur elles et leurs utilisations.

Mais pour l'interpréteur Ruby, ce n'est qu'une différence de nom.

En ce qui concerne votre deuxième observation, les classes imbriquées à l'intérieur des modules sont généralement utilisées pour l'espace de noms des classes. Par exemple:

module ActiveRecord
  class Base
  end
end

diffère de

module ActionMailer
  class Base
  end
end

Bien que ce ne soit pas la seule utilisation de classes imbriquées à l'intérieur de modules, c'est généralement la plus courante.

Dans Ruby, la définition d'une classe imbriquée est similaire à la définition d'une classe dans un module. Cela ne force pas réellement une association entre les classes, cela crée juste un espace de noms pour les constantes. (Les noms de classe et de module sont des constantes.)

La réponse acceptée n'était correcte sur rien. ¹ Dans l'exemple ci-dessous, je crée une instance de la classe lexicalement incluse sans qu'une instance de la classe englobante n'existe jamais.

class A; class B; end; end
A::B.new

Les avantages sont les mêmes que ceux des modules: encapsulation, regroupement du code utilisé à un seul endroit, et rapprochement du code de l'endroit où il est utilisé. Un grand projet peut avoir un module externe qui se produit à plusieurs reprises dans chaque fichier source et contient un grand nombre de définitions de classe. Lorsque les différents frameworks et codes de bibliothèque font tous cela, ils ne fournissent qu'un seul nom chacun au niveau supérieur, ce qui réduit les risques de conflits. Prosaic, bien sûr, mais c'est pourquoi ils sont utilisés.

L'utilisation d'une classe au lieu d'un module pour définir l'espace de noms externe peut avoir du sens dans un programme ou un script à un fichier, ou si vous utilisez déjà la classe de niveau supérieur pour quelque chose, ou si vous allez réellement ajouter du code pour lier les classes entre elles dans un vrai style de classe interne . Ruby n'a pas de classes internes mais rien ne vous empêche de créer le même comportement dans le code. Référencer les objets externes à partir des objets internes nécessitera toujours un pointage à partir de l'instance de l'objet externe, mais l'imbrication des classes suggérera que c'est ce que vous pourriez faire. Un programme soigneusement modulaire peut toujours créer les classes englobantes en premier, et elles peuvent raisonnablement être décomposées avec des classes imbriquées ou internes. Vous ne pouvez pas appeler newun module.

Vous pouvez utiliser le modèle général même pour les scripts, où l'espace de noms n'est pas terriblement nécessaire, juste pour le plaisir et la pratique ...

#!/usr/bin/env ruby

class A
  class Realwork_A
    ...
  end
  class Realwork_B
    ...
  end

  def run
    ...
  end

  self
end.new.run

Vous souhaiterez probablement l'utiliser pour regrouper vos classes dans un module. Une sorte d'espace de noms.

par exemple, le gem Twitter utilise des espaces de noms pour y parvenir:

Twitter::Client.new

Twitter::Search.new

Donc, les deux Clientet les Searchclasses vivent sous le Twittermodule.

Si vous souhaitez vérifier les sources, le code des deux classes peut être trouvé ici et ici .

J'espère que cela t'aides!

Il y a encore une autre différence entre les classes imbriquées et les modules imbriqués dans Ruby avant la version 2.5 que d'autres réponses n'ont pas réussi à couvrir et qui, selon moi, doivent être mentionnées ici. C'est le processus de recherche.

En bref: en raison de la recherche constante de niveau supérieur dans Ruby avant la version 2.5, Ruby peut finir par rechercher votre classe imbriquée au mauvais endroit ( Objecten particulier) si vous utilisez des classes imbriquées.

Dans Ruby antérieur à 2.5:
Structure de classe imbriquée: supposons que vous ayez une classe X, avec une classe imbriquée Y, ou X::Y. Et puis vous avez une classe de haut niveau nommée également Y. Si X::Yn'est pas chargé, alors ce qui suit se produit lorsque vous appelez X::Y:

N'ayant pas trouvé Ydans X, Ruby essaiera de le rechercher dans les ancêtres de X. PuisqueXest une classe et non un module, elle a des ancêtres, parmi lesquels [Object, Kernel, BasicObject]. Donc, il essaie de chercher Ydans Object, où il le trouve avec succès.

Pourtant, c'est le plus haut niveau Yet non X::Y. Vous recevrez cet avertissement:

warning: toplevel constant Y referenced by X::Y

Structure de module imbriqué: Supposons que dans l'exemple précédent Xsoit un module et non une classe.

Un module n'a que lui-même comme ancêtre: X.ancestorsproduirait [X].

Dans ce cas, Ruby ne pourra pas rechercher Ydans l'un des ancêtres de Xet lancera un fichier NameError. Rails (ou tout autre framework avec chargement automatique) essaiera de se charger X::Yaprès cela.

Voir cet article pour plus d'informations: https://blog.jetbrains.com/ruby/2017/03/why-you-should-not-use-a-class-as-a-namespace-in-rails-applications/

In Ruby 2.5:
Suppression de la recherche constante de niveau supérieur.
Vous pouvez utiliser des classes imbriquées sans craindre de rencontrer ce bogue.

En plus des réponses précédentes: Le module en Ruby est une classe

$ irb
> module Some end
=> nil
> Some.class
=> Module
> Module.superclass
=> Object