ruby - Ruby のプレーンな古いオブジェクト?

Question

Ruby では、ベンダー API が結果を配列として返すのが非常に一般的であることに気付きました。Plain Old Objects (Java の POJO のような) はもっと標準的であるべきではありませんか? 独自のライブラリを作成する場合、POJOs POROs を使用するべきではありませんか?

Answer 1

配列とオブジェクトは誤った二分法だと思います。

API呼び出しが複数のものを返す場合、それが配列の形式であることは完全に合理的です（そして、配列はかなり単純なオブジェクトであるため、とにかくRubyではおそらく「PORO」です）

編集：あなたのコメントに応えて：

引用した例（http://github.com/cjheath/geoip）は、さまざまなアイテムの配列を返します。これが必ずしもデータを返すのに最適な形式ではないことに同意します。その場合、適切な名前のキーを使用したハッシュの方が優れた構造になると思います。

John Topleyが言うように、RubyのOOの性質は、ハッシュが可能な限り単純であるため、人々が「PORO」などの用語を発明する必要がないことを意味します。

Answer 2

それは常にすべてのオブジェクトです。重要なのは、返されるオブジェクトに動作が関連付けられているかどうかです。これを行うのは問題ありません：

  def read_first_and_last_name(data_source)
    [data_source.read_string, data_source.read_string]
  end

しかし、それらのデータ項目に関連付けられた動作があることに気付いた瞬間...

  def print_name(first_name, last_name)
    puts "#{first_name} #{last_name}"
  end

  def read_and_print_name
    first_name, last_name = read_first_and_last_name(data_source)
    print_name(first_name, last_name)
  end

...そして、それらはクラスでなければなりません:

  class FullName

    def FullName.read(data_source)
      FullName.new(data_source.read_string, data_source.read_strng)
    end

    def initialize(first_name, last_name)
      @first_name = first_name
      @last_name = last_name
    end

    def print
      puts "#{@first_name} #{@last_name}"
    end

  end

名前の動作が適切にカプセル化されているため、使用法は次のように単純になります。

  def read_and_print_name
    FullName.read(data_source).print
  end

Answer 3

これらの結果の配列には何が含まれていますか? 答えは、Ruby ではすべてがオブジェクトであるため、Ruby ではオブジェクトが含まれているということです。

Java の世界における POJO は、EJB などのエンタープライズ Java によって世界に与えられた複雑さに対する反応でした。この用語を作り出したマーティン・ファウラーの言葉を引用すると、

「私たちは、人々が自分のシステムで通常のオブジェクトを使用することに反対する理由を疑問に思い、単純なオブジェクトには派手な名前がないためだと結論付けました。それで名前を付けたところ、非常にうまく受け入れられました。」

幸いなことに、Ruby では、人々がオブジェクト指向プログラミングを練習するだけで、その周りの用語を発明する必要がなくなりました。

Answer 4

私は個人的に、完全な使い捨てスクリプトではない、私が書いたほとんどすべてのもので PORO を使用しています。

特定のタイプの複数のオブジェクトを管理および保持し、いくつかのヘルパー メソッドを含むクラスのデータ ホルダー タイプを作成することがよくあります。これは、他の誰かが私のコードでも作業する必要がある場合に便利です。

常に正しい答えがあるわけではないという意味で、この質問は非常に主観的だと思います。配列を返すだけでよい場合もあり、追加のクラスを作成する必要はありません。場合によっては、抽象化の追加レベルにより、ユーザーにとって何かがより明確になります。