Коли використовувати вкладені класи та класи, вкладені в модулі?

Я досить добре знайомий з тим, як використовувати підкласи та модулі, але останнім часом я бачив такі вкладені класи:

class Foo
  class Bar
    # do some useful things
  end
end

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

module Baz
  class Quux
    # more code
  end
end

Або документація, і статті є рідкісними, або я недостатньо освічений з цього питання, щоб шукати потрібні пошукові терміни, але я не можу знайти багато інформації з цієї теми.

Чи може хтось навести приклади чи посилання на повідомлення про те, чому / коли будуть використовуватися ці методи?

Інші мови OOP мають внутрішні класи, які неможливо створити інстанціювати, не будучи прив’язаними до класу верхнього рівня. Наприклад, у Java,

class Car {
    class Wheel { }
}

тільки методи в Carкласі можуть створювати Wheels.

У Рубі такої поведінки немає.

У Рубі,

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].

У цьому випадку Рубі не зможе шукати Yкогось із предків Xі кине а NameError. Рейки (або будь-який інший фреймворк з автоматичним завантаженням) намагатимуться завантажити X::Yпісля цього.

Додаткову інформацію див.

У цій статті: https://blog.jetbrains.com/ruby/2017/03/why-you-should-not-use-a-class-as-a-namespace-in-rails-applications/ In Ruby 2.5:
Постійний пошук верхнього рівня видалено.
Ви можете використовувати вкладені класи, не побоюючись зустріти цю помилку.

На додаток до попередніх відповідей: Модуль в Ruby - це клас

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