web-dev-qa-db-ja.com

Rubyで名前空間に名前を付けるための好ましい方法（より良いスタイル）は何ですか？単数形または複数形？

使用の長所と短所は何ですか：

FooLib::Plugins
FooLib::Plugins::Bar

vs.

FooLib::Plugin
FooLib::Plugin::Bar

命名規則？そして、あなたは何を使いますか、それとも何を使いますか？コミュニティでより一般的に使用されているものは何ですか？

rubymodulenamespacesnaming-conventionsnaming
28
Szymon Jeż

使用する：

module FooLib end
module FooLib::Plugins end
class  FooLib::Plugins::Plugin; end #the base for plugins
class  FooLib::Plugins::Bar < FooLib::Plugins::Plugin; end
class  FooLib::Plugins::Bar2 < FooLib::Plugins::Plugin; end

または別の言葉で：

module FooLib
  module Plugins
    class Plugin; end #the base for plugins
    class Bar < Plugin; end
    class Bar2 < Plugin; end
  end
end

また、次のようにファイルを配置します。

- foo_lib/
  - plugins/
    - plugin.rb
    - bar.rb
    - bar2.rb

これは how Rails do it （つまり、これはRails Way）です。つまり、Associations名前空間と-を見てください。 Associations :: Associationクラス すべてのクラスがAssociations名前空間を形成します（つまり Associations :: SingularAssociation ）。

20
Szymon Jeż

私には、FooLib::Pluginsはモジュールのように見え、さまざまなプラグインクラスが保持される名前空間として使用されます。FooLib::PluginはFooLibプラグインのスーパークラスのように見えます。

FooLib::Plugins::Barでは、Barは間違いなくプラグインの名前のようです。 FooLib::Plugin::Barを使用すると、BarがFoo::Pluginによって使用されるヘルパークラスなのか、プラグインの名前なのか疑問に思います。

13
Alex D

Pluginが基本クラスであると仮定します。

  • class FooLib::Plugin::Bar < FooLib::Plugin

    これは私が使用してお勧めするものです。 BarはPluginのFooLibですおよびFooLib::Pluginから継承します。また、FooLibライブラリによって提供されるプラグインを、一般クラスの名前空間の下にネストされたままにします。

    # Assign the Bar Plugin of the FooLib library to p.
p = FooLib::Plugin::Bar

    ライブラリ用のサードパーティプラグインを開発する場合は、次の構造を作成します。

    # Baz is a Plugin for the FooLib library provided by BarLib.
class BarLib::FooLib::Plugin::Baz < ::FooLib::Plugin

    FooLib階層をミラーリングしていますが、BarLibの名前空間の下にあることに注意してください。私はそれを直接拡張しません。

  • class FooLib::Plugins::Bar < FooLib::Plugin

    私もこれを使ったことがありますが、それが一番理にかなっていると思います。 BarはFooLib::Pluginを拡張し、Pluginsによって提供されるFooLibの1つです。ただし、不要になる可能性のあるモジュールが作成されます。

    PluginsがPlugins.add、Plugins.all、Plugins.loadedなどのメソッドを実装する中央プラグインリポジトリである場合、これは素晴らしい選択だと思います。

    追加のモジュールを正当化できる場合は、これを使用してください。

  • class FooLib::Plugins::Bar < FooLib::Plugins

    私にはあまり意味がありません。 BarはPluginsのFooLibの1つであり、その部分は問題ないように見えます。ただし、Pluginsから継承します。複数のプラグインから継承していますか？それは私には奇妙に聞こえます。クラス名は、不可能なことを示唆するものであってはなりません。

4
Matheus Moreira

@jtrimによって概説されたアプローチを2番目にします。

モジュール（つまりプラグイン）が名前空間にのみ使用されていることを考えると、私は通常、モジュールの新しいメソッドをオーバーライドします。

module Foo
  module Plugin

    def self.included(base)
      raise "cannot be included"
    end

    def self.extended(base)
      raise "cannot extend"
    end

    def self.new(*args)
      Base.new(*args)
    end

    class Base;end
  end
end


base_plugin_obj = Foo::Plugin.new(...)
2
Chetan Patil

一般的に、私が採用する傾向があるアプローチは次のとおりです。

module Foo
  module Plugin
    class Base; end
  end
end

class Foo::Plugin::Bar < Foo::Plugin::Base; end

プラグインのBaseクラスは、RubyOnRailsコードベースや他の多くの場所で見られる規則です。 （例：ActiveRecord::Base、ActionController::Baseなど）

@MatheusMoreiraのアプローチに同意しません。Foo::Pluginは、プラグインの基本クラスと名前空間の両方として使用されます。

これを行うべきではない唯一の機能的な理由は、慣習に関係しています-Rubyコミュニティでは、モジュールよりも名前空間としてクラスのインスタンスがはるかに少なくなります。私が実際にクラスを見るのはこのときだけです。別のクラスの名前空間として使用されるのは、そのクラスの目的が名前空間クラスに対してプライベートであり、外部で使用されていない場合です。

1
jtrim