¿Cuándo usar clases anidadas y clases anidadas en módulos?

Estoy bastante familiarizado con cuándo usar subclases y módulos, pero más recientemente he estado viendo clases anidadas como esta:

class Foo
  class Bar
    # do some useful things
  end
end

Además de clases anidadas en módulos de esta manera:

module Baz
  class Quux
    # more code
  end
end

O bien la documentación y los artículos son escasos o no estoy bien informado sobre el tema para buscar los términos de búsqueda correctos, pero parece que no puedo encontrar mucha información sobre el tema.

¿Podría alguien proporcionar ejemplos o enlaces a publicaciones sobre por qué / cuándo se utilizarían esas técnicas?

Otros lenguajes OOP tienen clases internas que no se pueden instanciar sin estar vinculadas a una clase de nivel superior. Por ejemplo, en Java,

class Car {
    class Wheel { }
}

solo los métodos en la Carclase pueden crear Wheels.

Ruby no tiene ese comportamiento.

En rubí

class Car
  class Wheel
  end
end

difiere de

class Car
end

class Wheel
end

sólo en el nombre de la clase Wheelvs Car::Wheel. Esta diferencia de nombre puede hacer explícito a los programadores que la Car::Wheelclase solo puede representar una rueda de automóvil, en lugar de una rueda general. Anidar definiciones de clase en Ruby es una cuestión de preferencia, pero tiene un propósito en el sentido de que impone un contrato más fuerte entre las dos clases y al hacerlo transmite más información sobre ellas y sus usos.

Pero para el intérprete de Ruby, solo es una diferencia de nombre.

En cuanto a su segunda observación, las clases anidadas dentro de los módulos generalmente se usan para asignar espacios de nombres a las clases. Por ejemplo:

module ActiveRecord
  class Base
  end
end

difiere de

module ActionMailer
  class Base
  end
end

Aunque este no es el único uso de clases anidadas dentro de módulos, generalmente es el más común.

En Ruby, definir una clase anidada es similar a definir una clase en un módulo. En realidad, no fuerza una asociación entre las clases, solo crea un espacio de nombres para las constantes. (Los nombres de clase y módulo son constantes).

La respuesta aceptada no era correcta sobre nada. ¹ En el ejemplo a continuación, creo una instancia de la clase encerrada léxicamente sin que exista una instancia de la clase encerradora.

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

Las ventajas son las mismas que para los módulos: encapsulación, agrupación de código utilizado en un solo lugar y colocación de código más cerca de donde se utiliza. Un proyecto grande puede tener un módulo externo que ocurre una y otra vez en cada archivo fuente y contiene muchas definiciones de clase. Cuando los diversos marcos y códigos de biblioteca hacen esto, solo contribuyen con un nombre al nivel superior, lo que reduce la posibilidad de conflictos. Prosaico, sin duda, pero es por eso que se usan.

El uso de una clase en lugar de un módulo para definir el espacio de nombres externo puede tener sentido en un programa o script de un archivo, o si ya usa la clase de nivel superior para algo, o si realmente va a agregar código para vincular las clases juntas en verdadera clase interna estilo de . Ruby no tiene clases internas, pero nada le impide crear el mismo comportamiento en el código. Hacer referencia a los objetos externos de los internos aún requerirá puntear desde la instancia del objeto externo, pero anidar las clases sugerirá que esto es lo que podría estar haciendo. Un programa cuidadosamente modularizado siempre puede crear primero las clases que lo encierran, y razonablemente se pueden descomponer con clases anidadas o internas. No puedes llamar newa un módulo.

Puede usar el patrón general incluso para scripts, donde el espacio de nombres no es muy necesario, solo por diversión y práctica ...

#!/usr/bin/env ruby

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

  def run
    ...
  end

  self
end.new.run

Probablemente quiera usar esto para agrupar sus clases en un módulo. Una especie de espacio de nombres.

por ejemplo, la gema de Twitter usa espacios de nombres para lograr esto:

Twitter::Client.new

Twitter::Search.new

Entonces, ambos Clienty las Searchclases viven bajo el Twittermódulo.

Si desea verificar las fuentes, el código para ambas clases se puede encontrar aquí y aquí .

¡Espero que esto ayude!

Hay otra diferencia entre las clases anidadas y los módulos anidados en Ruby antes de 2.5 que otras respuestas no pudieron cubrir y creo que deben mencionarse aquí. Es el proceso de búsqueda.

En resumen: debido a la búsqueda constante de nivel superior en Ruby antes de 2.5, Ruby puede terminar buscando su clase anidada en el lugar incorrecto ( Objecten particular) si usa clases anidadas.

En Ruby anterior a 2.5:
Estructura de clase anidada: suponga que tiene una clase X, con clase anidada Y, o X::Y. Y luego tienes una clase de nivel superior llamada también Y. Si X::Yno está cargado, entonces ocurre lo siguiente cuando se llama X::Y:

Al no haber encontrado Yen X, Ruby va a tratar de mirar hacia arriba en los antepasados de X. Ya queXes una clase y no un módulo, tiene ancestros, entre los cuales se encuentran [Object, Kernel, BasicObject]. Entonces, trata de buscar Yadentro Object, donde lo encuentra con éxito.

Sin embargo, es el nivel superior Yy no X::Y. Recibirá esta advertencia:

warning: toplevel constant Y referenced by X::Y

Estructura de módulo anidado: suponga que en el ejemplo anterior Xes un módulo y no una clase.

Un módulo solo se tiene a sí mismo como ancestro: X.ancestorsproduciría [X].

En este caso, Ruby no podrá buscar a Yuno de sus antepasados Xy lanzará un NameError. Los rieles (o cualquier otro marco con carga automática) intentarán cargarse X::Ydespués de eso.

Consulte este artículo para obtener más información: https://blog.jetbrains.com/ruby/2017/03/why-you-should-not-use-a-class-as-a-namespace-in-rails-applications/

In Ruby 2.5: Se
eliminó la búsqueda constante de nivel superior.
Puede usar clases anidadas sin temor a encontrar este error.

Además de las respuestas anteriores: Módulo en Ruby es una clase

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