1

私の友人とのさらに別の議論。次のコードを検討してください。

class User < ActiveRecord::Base
  has_many :groups
  def in_group?(group)
      groups.include?(group)
  end
end
class Group < ActiveRecord::Base
  has_many :members
  def add_user(user)
      members << user
  end
end

私の意見では、これらのメソッドはコードに不必要な複雑さを追加し、ほとんど推測できません。たとえば、なぜ #in_group? #is_a_member_of? ではない、または #add_user でありながら #add_member ではない理由など。Rails での 4 年間の経験と合計 20 年間のプログラミング経験から、AR セマンティクスに従い、User#groups.include?(group) と Group#members << user を使用した方がよいでしょう。それらは簡単に推測でき、追加機能が必要な場合に備えて、has_many :members のコールバックを使用して、User#groups.include? をオーバーライドできます。必要な場合は、関連拡張モジュールで。

ただし、私の友人は、ショートカットを使用して「抽象化のポイント」を作成する方が良いと主張しており、コールバックやオーバーロードを使用するよりもこのコードを拡張する方が良いと主張しています。

どう思いますか？

PS明確にするために、私は「WHAT IF」アプローチが嫌いです:)

4

5 に答える 5

2

これらのメソッドを追加すべきではないことに完全に同意します。他の関連オブジェクトを作成するのはモデルの仕事ではありません。それがアソシエーション プロキシの仕事です。プロキシの実装方法が原因で奇妙な副作用が発生する可能性があるため、関連付けプロキシの動作をオーバーライドすることにも注意してください。

于 2009-02-08T18:35:21.370 に答える
1

あなたが引用したスタイルは、「デメテルの法則」の下で擁護できます。これは、クライアントコードの操作groupsまたはmembers直接に対して警告します。

于 2009-02-08T18:50:50.620 に答える
0

For in_group?: メソッド名は一方向に推測できます — 読んだときに何をするかは明らかです。これは重要な種類の推測可能です。in_group?誰かがこのコードを維持しているとき、彼は電話に巻き込まれることはありません。また、より宣言的で簡潔であるため、読みやすさが向上します (この場合はわずかですが、原則としては適切です)。これは Smalltalky のような方法です。

一方で、add_userメソッドは不要だと思います。特に簡潔でも直接的でもないように見えますが、標準的ではありません。名前はまだかなり明白で、ひどく有害ではありませんが、その利点はわかりません. 近道というより、風光明媚なルートのようです。

于 2009-02-08T18:44:00.663 に答える