Kiedy używać klas zagnieżdżonych i klas zagnieżdżonych w modułach?

Wiem, kiedy używać podklas i modułów, ale ostatnio widziałem takie zagnieżdżone klasy:

class Foo
  class Bar
    # do some useful things
  end
end

Oprócz klas zagnieżdżonych w modułach, takich jak:

module Baz
  class Quux
    # more code
  end
end

Albo dokumentacja i artykuły są skąpe, albo nie jestem wystarczająco wykształcony na ten temat, aby znaleźć odpowiednie wyszukiwane hasła, ale nie mogę znaleźć wielu informacji na ten temat.

Czy ktoś mógłby podać przykłady lub linki do postów o tym, dlaczego / kiedy te techniki zostaną użyte?

Inne języki OOP mają klasy wewnętrzne, których nie można utworzyć bez powiązania z klasą wyższego poziomu. Na przykład w Javie

class Car {
    class Wheel { }
}

tylko metody w Carklasie mogą tworzyć Wheels.

Ruby nie ma takiego zachowania.

W Rubim

class Car
  class Wheel
  end
end

różni się od

class Car
end

class Wheel
end

tylko w nazwie klasy Wheelvs. Car::Wheel. Ta różnica w nazwie może wyraźnie wskazywać programistom, że Car::Wheelklasa może reprezentować tylko koło samochodowe, w przeciwieństwie do koła ogólnego. Zagnieżdżanie definicji klas w Rubim jest kwestią preferencji, ale służy celowi w tym sensie, że silniej wymusza kontrakt między dwiema klasami, a tym samym przekazuje więcej informacji o nich i ich zastosowaniach.

Ale dla interpretera Rubiego to tylko różnica w nazwie.

Jeśli chodzi o drugą obserwację, klasy zagnieżdżone w modułach są zwykle używane do określania przestrzeni nazw klas. Na przykład:

module ActiveRecord
  class Base
  end
end

różni się od

module ActionMailer
  class Base
  end
end

Chociaż nie jest to jedyne użycie klas zagnieżdżonych w modułach, jest na ogół najpowszechniejsze.

W Rubim definiowanie klasy zagnieżdżonej jest podobne do definiowania klasy w module. W rzeczywistości nie wymusza asocjacji między klasami, po prostu tworzy przestrzeń nazw dla stałych. (Nazwy klas i modułów są stałymi).

Przyjęta odpowiedź nie była w niczym poprawna. ¹ W poniższym przykładzie tworzę instancję klasy zamkniętej leksykalnie bez instancji tej klasy kiedykolwiek istniejącej.

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

Korzyści są takie same jak w przypadku modułów: hermetyzacja, grupowanie kodu używanego tylko w jednym miejscu i umieszczanie kodu bliżej miejsca, w którym jest używany. Duży projekt może mieć jeden moduł zewnętrzny, który pojawia się wielokrotnie w każdym pliku źródłowym i zawiera wiele definicji klas. Kiedy różne frameworki i kody bibliotek robią to wszystko, wtedy dodają tylko jedną nazwę do najwyższego poziomu, zmniejszając ryzyko konfliktów. Z pewnością prozaiczne, ale dlatego są używane.

Używanie klasy zamiast modułu do definiowania zewnętrznej przestrzeni nazw może mieć sens w jednoplikowym programie lub skrypcie, lub jeśli używasz już do czegoś klasy najwyższego poziomu lub jeśli faktycznie zamierzasz dodać kod łączący klasy ze sobą w prawdziwie klasycznym stylu. Ruby nie ma klas wewnętrznych, ale nic nie stoi na przeszkodzie, abyś tworzył w kodzie takie samo zachowanie. Odwoływanie się do obiektów zewnętrznych do obiektów wewnętrznych nadal będzie wymagało dotarcia z wystąpienia obiektu zewnętrznego, ale zagnieżdżenie klas będzie sugerować, że właśnie to możesz robić. Starannie zmodularyzowany program może zawsze najpierw utworzyć otaczające klasy i rozsądnie można je rozłożyć na klasy zagnieżdżone lub wewnętrzne. Nie możesz wywołać newmodułu.

Możesz użyć ogólnego wzorca nawet dla skryptów, w których przestrzeń nazw nie jest strasznie potrzebna, tylko dla zabawy i ćwiczeń ...

#!/usr/bin/env ruby

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

  def run
    ...
  end

  self
end.new.run

Prawdopodobnie chcesz użyć tego do zgrupowania swoich klas w moduł. Coś w rodzaju przestrzeni nazw.

na przykład klejnot na Twitterze wykorzystuje przestrzenie nazw, aby to osiągnąć:

Twitter::Client.new

Twitter::Search.new

Tak więc obie Clienti Searchklasy mieszkają pod Twittermodułem.

Jeśli chcesz sprawdzić źródła, kod obu klas można znaleźć tutaj i tutaj .

Mam nadzieję że to pomoże!

Istnieje jeszcze inna różnica między klasami zagnieżdżonymi a modułami zagnieżdżonymi w Rubim przed wersją 2.5, której inne odpowiedzi nie uwzględniły, o czym moim zdaniem należy tutaj wspomnieć. To jest proces wyszukiwania.

W skrócie: z powodu wyszukiwania stałych najwyższego poziomu w Rubim przed 2.5, Ruby może skończyć szukać twojej zagnieżdżonej klasy w złym miejscu ( Objectw szczególności), jeśli używasz zagnieżdżonych klas.

W Rubim wcześniejszych niż 2.5:
Zagnieżdżona struktura klas: Załóżmy, że masz klasę Xz zagnieżdżoną klasą Ylub X::Y. A potem masz również klasę najwyższego poziomu Y. Jeśli X::Ynie jest załadowany, po wywołaniu dzieje się następująco X::Y:

Nie znaleziony Yw X, Ruby spróbuje wyszukać go u przodków X. OdXjest klasą, a nie modułem, ma przodków, wśród których są [Object, Kernel, BasicObject]. Tak, stara się szukać YIN Object, jeżeli uzna go pomyślnie.

Ale to najwyższy poziom Yi nie X::Y. Otrzymasz to ostrzeżenie:

warning: toplevel constant Y referenced by X::Y

Struktura modułu zagnieżdżonego: załóżmy, że w poprzednim przykładzie Xjest to moduł, a nie klasa.

Moduł ma tylko siebie jako przodka: X.ancestorsbędzie produkować [X].

W takim przypadku Ruby nie będzie w stanie szukać Yu jednego z przodków Xi wyrzuci plik NameError. Railsy (lub jakikolwiek inny framework z automatycznym ładowaniem) spróbują załadować się X::Ypóźniej.

Zobacz ten artykuł, aby uzyskać więcej informacji: https://blog.jetbrains.com/ruby/2017/03/why-you-should-not-use-a-class-as-a-namespace-in-rails-applications/

In Ruby 2.5:
Usunięto stałe wyszukiwanie najwyższego poziomu.
Możesz używać zagnieżdżonych klas bez obawy napotkania tego błędu.

Oprócz poprzednich odpowiedzi: Moduł w Rubim to klasa

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