Rails（5.0.0.1）で多態性と継承を混ぜる方法

Question

私は2日間の解決策を見つけようとしてきましたが、まだ何も出てこなかった。私には、また、Courseからの利益が、また、私のデータベースに他のモデルに利益をもたらすの列を、持っているContentモデルを持っている

create_table :courses do |c| 
    c.integer :member_limit 
    c.string :color 
    c.float :rating 

    c.timestamps 
end 

：

私は、次の列がありCourseと呼ばれるモデルを持っている

create_table :contents do |c| 
    c.references :contentable, polymorphic: true, index: true 
    c.string :title 
    c.text :description 
    c.text :script 
    c.string :cover 
    c.string :media_type 
    ... 
    c.integer :creator_id, index: true, foreign_key: :user_id 
end  

私はコースが内部などとして持つ列を失うことになるので、私はCourse < Contentを設定することはできませんなど、私はPolymorphicに行った。しかし、私はcourse.content.titleに電話してcourse.titleと書くだけでなく、同じ方法でcourse.member_limitにアクセスし、両方のフィールドをcourse.saveで保存する必要はありません。

最高のアプローチをお勧めしますか？

現在の構造。

コース：

class Course < ApplicationRecord 
    has_one :content, as: :contentable, dependent: :destroy 

    after_initialize :init 

    def init 
     if self.new_record? 
     self.content ||= build_content  
     end 
    end 
end 

内容：

class Content < ApplicationRecord 
    belongs_to :creator, optional: true, class_name: 'User' 
end 

Answer 1

私はあなたの前提はあなたが何をしたいのか行うべきではありませんという意味で間違っていると思います。私が説明：あなたが欲しい

は、そのようなヘルパーメソッドを介して行うことができます。醜いです

class Course < AR 
    def title 
    content.title 
    end 
end 

は、すべてのこれまでに書かれたコード化引数、およびそのちょうど悪い習慣に違反します。しかし、離れていくつかのメタマジックのためにヘルパーメソッドを1つずつ書く必要はありません（最終的に実装されるので、書いていることに気づきました）、最終結果はこのようにする必要があります。それ以外の方法はありません。だから私の答えは、これをしないでください。

多型を理解することは容易ではありません。実装は簡単ですが、いつ知るのは難しいです。あなたは他のいくつかのリソースの列を含む抽象的なボックスを必要とします。 「...コースのメリットだけでなく、他のモデルにもメリットをもたらすコラムを備えたコンテンツモデル」を作成するという決定には、あなたは推論しません。私は尋ねる。どうして？メリットは何ですか？なぜこれを行うのですか？期待どおりに働いていますか？それを使用して拡張するのは簡単ですか？カプセル化されていますか？乾燥していて、安静で、しっかりしていて、他のすべての頭字語が最近使用されていますか？

短い答えはいいえです。そうではありません。そうしないでください。コースにはタイトルがあります。別のテーブルにもタイトルがある場合、何ですか？世界のどのように多くのテーブルに "名前"という列があるか知っていますか？もしあなたがそれをあなたのやり方で実装したいのなら、私たちは次のようなものを持っています：

class School < Ar 
    belongs_to :name 

    def full_name 
    name.body 
    end 
end 

class Student < Ar 
    belongs_to :name 

    def full_name 
    name.body 
    end 
end 

これは明らかに有用ではありません。ですから、1つの列に役立たない場合、なぜそれがより多くの列に役立つのでしょうか？

結論：

1. 多型、再使用する列に決して使用されません。
2. 列の再利用にSTIが使用されています
3. 多態性は、複数のリソースにアタッチできるものとして理解できます。そのような：通知、ログ、アドレス...基本的にコースはアドレスを持っていると言うと、学生もアドレスを持っています。学生とコースの両方がアドレス可能です。しかし、決して決して内容がAタイプの住所であるとは決して言いません。これはどんな形でも真実ではありません。
4. STIでは、リソースが親のタイプをBECOMESするので、STIでは、コースはAタイプのコンテンツになります。また、学生はAタイプのコンテンツになります。しかし決して、決してCourse HASの内容は言ってはいけません。これはどんな形でも真実ではありません。

STIでは、コンテンツ表には、すべての列が「コースPLUS」のすべての列になり、他のどの表の列もコースになりました。これは、基本的に、データが同じまたはほとんど（あなたの説明のように思われる）、すべての子クラスでコードを繰り返すことを望まないリソースにとっては良い習慣です。すべてのSTIは、各子クラスで親クラスコードを繰り返すことでSTIなしで実装できます。

したがって、短い回答（少し遅れていませんか？）いいえ、あなたが望むことをすることはできません。あなたはどちらか

1. ただコンテンツを「共有」しているだろうすべてのリソースを表すために
2. 利用STIとONE TABLE（最初の実装、簡単、迅速かつ標準のための好適な方法を）各リソースの列を繰り返すことができます情報
3. 多態性を使用し、ヘルパーメソッドを使用して必要な処理を行います。しかし、アクセサは唯一のものではないことを忘れないでください。 def title=などの方法について考えてみてください。それらのすべてを再実装するつもりですか？

申し訳ありませんが、このミスを長すぎる回数だけ見ました。