Когда использовать вложенные классы и классы, вложенные в модули?

Я хорошо знаком с тем, когда использовать подклассы и модули, но совсем недавно я видел такие вложенные классы:

class Foo
  class Bar
    # do some useful things
  end
end

А также классы, вложенные в такие модули:

module Baz
  class Quux
    # more code
  end
end

Либо документация и статьи немногочисленны, либо я недостаточно осведомлен по этому вопросу, чтобы нащупать правильные условия поиска, но, похоже, я не могу найти много информации по теме.

Может ли кто-нибудь предоставить примеры или ссылки на сообщения о том, почему и когда будут использоваться эти методы?

В других языках ООП есть внутренние классы, которые не могут быть созданы без привязки к классу верхнего уровня. Например, в Java

class Car {
    class Wheel { }
}

только методы в Carклассе могут создавать Wheels.

У Ruby такого поведения нет.

В Ruby,

class Car
  class Wheel
  end
end

отличается от

class Car
end

class Wheel
end

только имя класса WheelVS. Car::Wheel. Это различие в названии может показать программистам, что Car::Wheelкласс может представлять только колесо автомобиля, а не колесо общего назначения. Вложенность определений классов в Ruby - это вопрос предпочтения, но он служит цели в том смысле, что более строго обеспечивает соблюдение контракта между двумя классами и тем самым передает больше информации о них и их использовании.

Но для интерпретатора Ruby это разница только в названии.

Что касается вашего второго наблюдения, классы, вложенные внутри модулей, обычно используются для пространства имен классов. Например:

module ActiveRecord
  class Base
  end
end

отличается от

module ActionMailer
  class Base
  end
end

Хотя это не единственное использование классов, вложенных внутри модулей, обычно оно наиболее распространено.

В Ruby определение вложенного класса похоже на определение класса в модуле. На самом деле он не вызывает ассоциации между классами, он просто создает пространство имен для констант. (Имена классов и модулей являются константами.)

Принятый ответ ни в чем не был правильным. В приведенном ниже примере я создаю экземпляр лексически замкнутого класса без когда-либо существовавшего экземпляра включающего класса.

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

Преимущества те же, что и для модулей: инкапсуляция, группировка кода, используемого только в одном месте, и размещение кода ближе к тому месту, где он используется. В большом проекте может быть один внешний модуль, который повторяется снова и снова в каждом исходном файле и содержит множество определений классов. Когда все различные фреймворки и библиотечные коды делают это, тогда они вносят только одно имя на верхний уровень, уменьшая вероятность конфликтов. Прозаика, конечно, но они поэтому и используются.

Использование класса вместо модуля для определения внешнего пространства имен может иметь смысл в однофайловой программе или скрипте, или если вы уже используете для чего-то класс верхнего уровня, или если вы действительно собираетесь добавить код для связывания классов вместе в истинном стиле внутреннего класса . Ruby не имеет внутренних классов, но ничто не мешает вам создать примерно такое же поведение в коде. Ссылка на внешние объекты из внутренних по-прежнему потребует расставления точек в экземпляре внешнего объекта, но вложенность классов предполагает, что это то, что вы могли бы делать. Тщательно модульная программа всегда может сначала создавать включающие классы, и их можно разумно разложить на вложенные или внутренние классы. Вы не можете вызвать newмодуль.

Вы можете использовать общий шаблон даже для сценариев, где пространство имен не очень необходимо, просто для развлечения и практики ...

#!/usr/bin/env ruby

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

  def run
    ...
  end
  
  self
end.new.run

Вероятно, вы захотите использовать это, чтобы сгруппировать свои классы в модуль. Что-то вроде пространства имен.

например, гем Twitter использует для этого пространства имен:

Twitter::Client.new

Twitter::Search.new

Так что оба класса Clientи Searchнаходятся под Twitterмодулем.

Если вы хотите проверить исходники, код для обоих классов можно найти здесь и здесь .

Надеюсь это поможет!

Есть еще одно различие между вложенными классами и вложенными модулями в Ruby до версии 2.5, которую другие ответы не смогли охватить, и я считаю, что здесь следует упомянуть. Это процесс поиска.

Вкратце: из-за поиска констант верхнего уровня в Ruby до версии 2.5 Ruby может в конечном итоге искать ваш вложенный класс в неправильном месте ( Objectв частности), если вы используете вложенные классы.

В Ruby до версии 2.5:
СтруктураX вложенного класса : предположим, у вас есть класс с вложенным классом Yили X::Y. И тогда у вас также есть класс верхнего уровня с именем Y. Если X::Yне загружен, то при вызове происходит следующее X::Y:

Не найдя Yв X, Ruby попытается найти его в предках X. посколькуXэто класс, а не модуль, у него есть предки, среди которых есть [Object, Kernel, BasicObject]. Таким образом, он пытается искать Yин Object, где он находит его успешно.

Все же это верхний уровень Yи нет X::Y. Вы получите это предупреждение:

warning: toplevel constant Y referenced by X::Y

Структура вложенного модуля: предположим, что в предыдущем примере Xэто модуль, а не класс.

Модуль имеет только самого себя в качестве предка: X.ancestorsбудет производить [X].

В этом случае Ruby не сможет искать Yв одном из предков Xи выбросит файл NameError. X::YПосле этого Rails (или любой другой фреймворк с автозагрузкой) попытается загрузиться .

См. Эту статью для получения дополнительной информации: https://blog.jetbrains.com/ruby/2017/03/why-you-should-not-use-a-class-as-a-namespace-in-rails-applications/

В Ruby 2.5:
удален поиск констант верхнего уровня.
Вы можете использовать вложенные классы, не опасаясь столкнуться с этой ошибкой.

В дополнение к предыдущим ответам: модуль в Ruby - это класс

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