Railsでのオブジェクト指向開発の秘密

本日は、今年のRuby Hero Awardの受賞者の1人であり、Rubyの信奉者である有名な開発者である Steve Klabnik（Steve Klabnik）の投稿の翻訳をご紹介します。 この報酬は何ですか？ 有意義な学習コンテンツの作成、プラグインと宝石の開発、オープンソースプロジェクトへの参加など、最も実績のあるコミュニティメンバーに昨年の受賞者から授与されます。 この賞は、最も自明な人々を称賛し、彼らにふさわしいという認識を与えるために創設されました。

今年11月5〜6日にキエフで開催されるRubyCカンファレンスでSteveと話すことができます。



私はよくRailsでRubyを教えたと人々に言います。 これは最悪の方法の1つですが、その頃にはすでに多くのプログラミング言語を学んでいたので、気にしませんでした。 ただし、これにより、Railsアプリケーションに必要なクラスがどれほど慎重に設計されているかについて、少しゆがんだ感覚が得られました。 幸いなことに、私は他人によって書かれたコードを偏見でレビューしており、私が尊敬する多くの人々の発展に重要なことが一つあることに気づきました。



これらの人々もこのことをユニークだと考えているようです。 これは、良いコードの書き方を知らない人が試してみるときではありませんが、それでもひどく判明します。 それは旗、信号のようなものです。 さて、私が誰かがこのことをどのように実装するかを見たとき、私はすぐに考えます：「彼はumbleる」。 私は自分の気持ちを信じすぎるかもしれませんが、この高度な開発手法は、Railsアプリケーションに相互接続された多くの利点を提供し、使いやすく、テストを1桁以上高速化します。 残念ながら、多くの初心者のRails開発者にとってこれは明らかではありませんが、コードをより良く書いていただきたいと思います。







「古いシンプルなRubyオブジェクト」と呼ばれます



はい、正確に。 Rubyは何も継承しないクラスです。 とてもシンプルなので、目立つ場所に隠されています。 Railsの作成者に愛されている、古いシンプルなRubyオブジェクト、または「PORO」は、一部の人々がそれらを呼ぶことを好むように、複雑さに対する隠された武器です。 これが私の意味です。 この「単純な」モデルを検討してください。

Copy Source | Copy HTML class Post < ActiveRecord::Base def self .as_dictionary dictionary = ( 'A' .. 'Z' ).inject({}) {|h, l| h[l] = []; h} Post .all.each do | p | dictionary[ p .title[ 0 ]] << p end dictionary end end

1. Copy Source | Copy HTML class Post < ActiveRecord::Base def self .as_dictionary dictionary = ( 'A' .. 'Z' ).inject({}) {|h, l| h[l] = []; h} Post .all.each do | p | dictionary[ p .title[ 0 ]] << p end dictionary end end
   
   
   
   
2. Copy Source | Copy HTML class Post < ActiveRecord::Base def self .as_dictionary dictionary = ( 'A' .. 'Z' ).inject({}) {|h, l| h[l] = []; h} Post .all.each do | p | dictionary[ p .title[ 0 ]] << p end dictionary end end
   
   
   
   
3. Copy Source | Copy HTML class Post < ActiveRecord::Base def self .as_dictionary dictionary = ( 'A' .. 'Z' ).inject({}) {|h, l| h[l] = []; h} Post .all.each do | p | dictionary[ p .title[ 0 ]] << p end dictionary end end
   
   
   
   
5. Copy Source | Copy HTML class Post < ActiveRecord::Base def self .as_dictionary dictionary = ( 'A' .. 'Z' ).inject({}) {|h, l| h[l] = []; h} Post .all.each do | p | dictionary[ p .title[ 0 ]] << p end dictionary end end
   
   
   
   
6. Copy Source | Copy HTML class Post < ActiveRecord::Base def self .as_dictionary dictionary = ( 'A' .. 'Z' ).inject({}) {|h, l| h[l] = []; h} Post .all.each do | p | dictionary[ p .title[ 0 ]] << p end dictionary end end
   
   
   
   
7. Copy Source | Copy HTML class Post < ActiveRecord::Base def self .as_dictionary dictionary = ( 'A' .. 'Z' ).inject({}) {|h, l| h[l] = []; h} Post .all.each do | p | dictionary[ p .title[ 0 ]] << p end dictionary end end
   
   
   
   
9. Copy Source | Copy HTML class Post < ActiveRecord::Base def self .as_dictionary dictionary = ( 'A' .. 'Z' ).inject({}) {|h, l| h[l] = []; h} Post .all.each do | p | dictionary[ p .title[ 0 ]] << p end dictionary end end
   
   
   
   
10. Copy Source | Copy HTML class Post < ActiveRecord::Base def self .as_dictionary dictionary = ( 'A' .. 'Z' ).inject({}) {|h, l| h[l] = []; h} Post .all.each do | p | dictionary[ p .title[ 0 ]] << p end dictionary end end
    
    
    
    
11. Copy Source | Copy HTML class Post < ActiveRecord::Base def self .as_dictionary dictionary = ( 'A' .. 'Z' ).inject({}) {|h, l| h[l] = []; h} Post .all.each do | p | dictionary[ p .title[ 0 ]] << p end dictionary end end
    
    
    
    

すべての投稿の最初の文字でインデックスを表示します。 これを行うには、辞書を作成し、そこに投稿を配置します。 リストをページに分割する必要がないので、データベースからのすべての投稿のリクエストに注意を払わないとします。 アイデアは重要です。すべての投稿を名前で表示できるようになりました。

Copy Source | Copy HTML

1. -Post.as_dictionary do |レター、リスト|
2. ％ p =文字
3. ％ul
4. -list.each do | post |
5. ％li = link_to post

もちろん。 一方で、コードは悪くありません。 しかし、それも良くありません。ビジネスロジック用に設計されたモデル内のプレゼンテーションが心配です。 プレゼンターパターンを使用してこれを修正しましょう。

Copy Source | Copy HTML

1. クラス DictionaryPresenter
2. def initialize （コレクション）
3. @collection =コレクション
4. 終わり
6. def as_dictionary
7. 辞書=（ 'A' .. 'Z' ）.inject（{}）{| h、l | h [l] = []; h}
9. @ collection.each do | p |
10. 辞書[ p .title [ 0 ]] << p
11. 終わり
13. 辞書
14. 終わり
15. 終わり

これで、DictionaryPresenter.new（Post.all）.as_dictionaryを使用できます。 これには多くの利点があります。モデルからプレゼンテーションロジックを削除しました。 すでに新しい機能が追加されています。どのコレクションもポインタで表示できるようになりました。 この代表的なクラスに対して個別のテストを簡単に書くことができ、それらは高速になります。



代表パターンに対する私の愛にもかかわらず、この投稿は彼に関するものではありません。 この原則は、「この概念は独自のクラスに値する」という他の場所にも現れています。 別の例に移る前に、この例を拡張しましょう。投稿を名前で並べ替える場合、このクラスは機能しますが、ユーザーにはタイトル（タイトルフィールド）がないため、たとえばユーザーを表示することはできません。 さらに、名前は記事「a」で始まることが多いため、「A」に関する多数の投稿を受け取ります。実際、2番目の単語の最初の文字が必要です。 2種類の代表者を作成できますが、コミュニティが失われ、「インデックス」の概念に再び2人の代表者がシステムに追加されます。 あなたが正しく理解したように：POROは私たちを救います！



代表を少し変更して、ポリシーオブジェクトを受け入れます。

Copy Source | Copy HTML

1. クラス DictionaryPresenter
2. def 初期化 （ポリシー、コレクション）
3. @policy =ポリシー
4. @collection =コレクション
5. 終わり
7. def as_dictionary
8. 辞書=（ 'A' .. 'Z' ）.inject（{}）{| h、l | h [l] = []; h}
10. @ collection.each do | p |
11. 辞書[@ policy.category_for（ p ）] << p
12. 終わり
14. 辞書
15. 終わり
16. 終わり

これで、ポリシーを追加して、異なるポリシーを作成できます。

Copy Source | Copy HTML

1. クラス UserCategorizationPolicy
2. def self .category_for（ユーザー）
3. user.username [ 0 ]
4. 終わり
5. 終わり
7. クラス PostCategorizationPolicy
8. def self .category_for（投稿）
9. if post.starts_with？（ "A" ）
10. post.title。 split [ 1 ] [ 0 ]
11. 他に
12. post.title [ 0 ]
13. 終わり
14. 終わり
15. 終わり

バム！

Copy Source | Copy HTML

1. DictionaryPresenter。 新規 （PostCategorizationPolicy、Post.all）.as_dictionary

はい、少し長くなっています。 それは起こります:)しかし今、あなたは各概念が私たちのシステムに一つのアイデアを持っていることがわかります。 代表者は、物事がどのように配置されるかを気にせず、政治家だけがそれらがどのように配置されるかを指示します。 実際、私の名前は少しがらくたです。おそらく、実際には「UsernamePolicy」または「TitlePolicy」と呼ぶ方が良いでしょう。 私たちは彼らがどんなクラスなのかさえ気にしません！



そしてすべてにおいて。 Rubyの柔軟性と「継承コードを使用した効果的な作業」の私のお気に入りの例を組み合わせることで、複雑な計算をオブジェクトに変えることができます。 このコードを見てください：

Copy Source | Copy HTML

1. クラス Quote < ActiveRecord :: Base
2. ＃<snip>
3. def pretty_turnaround
4. ターンアラウンドの場合は 「」を 返します。 ゼロ ？
5. purchase_atの場合
6. オフセット= purchase_at
7. days_from_today =（（ Time .now-purchase_at.to_time）/ 60/60/24）.floor + 1
8. 他に
9. オフセット= Time .now
10. days_from_today =所要時間+ 1
11. 終わり
12. 時間=オフセット+（ターンアラウンド* 60 * 60 * 24 ）
13. if （time.strftime（ "％a" ）== "Sat" ）
14. 時間+ = 2 * 60 * 60 * 24
15. elsif （time.strftime（ "％a" ）== "Sun" ）
16. 時間+ = 1 * 60 * 60 * 24
17. 終わり
19. 「＃{time.strftime（ " ％A％d％B "）}（＃{days_from_today}今日から営業日）」
20. 終わり
21. 終わり

ああ！ このメソッドは戻り（計算）時間を表示しますが、ご覧のとおり、これは複雑な計算です。 メソッド抽出（Method Extractリファクタリングメソッド）を数回使用して分割すると、これをより簡単に理解できますが、時間の計算にのみ必要な多くのコードでQuoteクラスを詰まらせる危険があります。 また、モデルがプレゼンテーションロジックを実装しているという事実を見ないでください。これは面倒なコードの例にすぎません。



したがって、このリファクタリングの最初のステップは、Feather（「レガシーコードを効果的に使用する」の著者）が「メソッドオブジェクトのブレークアウト」と呼ぶものです。 330ページの「レガシーコードを効果的に使用する」のコピーを開き、詳細を読むことができます。 持っていない場合は、購入してください:)。 実際、気が散ってしまいました。 アクションプランは次のとおりです。

1.新しい計算クラスを作成します。

2.新しい方法で作業する方法を定義します。

3.古いメソッドの本体をコピーし、ポインターへの参照をオブジェクトに置き換えます。

4.ステップ3で使用される変数を割り当てるための引数を取るコンストラクターを作成します。

5.古いメソッドを新しいクラスとメソッドに委任します。



コンパイラ（Lean On The Compiler）に頼ることができないため、Rubyの元のテンプレートを少し変更し、Featherがこれに対処するいくつかの手順を実行しました。 とにかく、このコードを試してみましょう。 ステップ1：

Copy Source | Copy HTML

1. クラス Quote < ActiveRecord :: Base
2. def pretty_turnaround
3. ＃スニップ
4. 終わり
6. クラス TurnaroundCalculator
7. 終わり
8. 終わり

第二：

Copy Source | Copy HTML

1. クラス TurnaroundCalculator
2. def 計算
3. 終わり
4. 終わり

第三：

Copy Source | Copy HTML

1. クラス TurnaroundCalculator
2. def 計算
3. @turnaroundの場合は 「」を返します。 ゼロ ？
4. if @purchased_at
5. オフセット= @purchased_at
6. days_from_today =（（ Time .now-purchase_at.to_time）/ 60/60/24）.floor + 1
7. 他に
8. オフセット= Time .now
9. days_from_today = @turnaround + 1
10. 終わり
11. 時間=オフセット+（@ターンアラウンド* 60 * 60 * 24 ）
12. if （time.strftime（ "％a" ）== "Sat" ）
13. 時間+ = 2 * 60 * 60 * 24
14. elsif （time.strftime（ "％a" ）== "Sun" ）
15. 時間+ = 1 * 60 * 60 * 24
16. 終わり
18. 「＃{time.strftime（ " ％A％d％B "）}（＃{days_from_today}今日から営業日）」
19. 終わり
20. 終わり

最初に通常の名前を付けて、彼が正確に何をするのかが明確になった後、ステップ5で名前を変更したいです。 ほとんどの場合、コード自体が適切な名前を教えてくれます。



4番目：

Copy Source | Copy HTML

1. クラス TurnaroundCalculator
2. def 初期化 （purchased_at、ターンアラウンド）
3. @purchased_at = purchase_at
4. @turnaround =ターンアラウンド
5. 終わり
7. def 計算
8. ＃スニップ
9. 終わり
10. 終わり

5番目：

Copy Source | Copy HTML

1. クラス Quote < ActiveRecord :: Base
2. def pretty_turnaround
3. TurnaroundCalculator。 新規 （purchased_at、ターンアラウンド）.calculate
4. 終わり
5. 終わり

できた！ テストを実行し、どのように合格するかを確認する必要があります。 「テストを実行する」とは、手動でチェックすることを意味する場合でも...



それでは、利点は何ですか？ さて、これでリファクタリングプロセスを開始できますが、私たちは自分の小さなクリーンルームにいます。 Quoteクラスを詰まらせることなくTurnaroundCalcuatorクラスにメソッドを追加できます。Calculatorのみのクイックテストを記述し、後で簡単に変更できるコンピューティングのアイデアを1か所で分解できます。 いくつかのリファクタリング後のクラスは次のとおりです。

Copy Source | Copy HTML

1. クラス TurnaroundCalculator
2. def 計算
3. @turnaroundの場合は 「」を返します。 ゼロ ？
5. 「＃{arrival_date}（＃{days_from_today}本日からの営業日）」
6. 終わり
8. 保護された
10. def 到着日
11. real_turnaround_time .strftime（ "％A％d％B" ）
12. 終わり
14. def real_turnaround_time
15. adjust_time_for_weekends （ start_time + turnaround_in_seconds ）
16. 終わり
18. def adjust_time_for_weekends （時間）
19. if saturday ？（時間）
20. 時間+ 2 * 60 * 60 * 24
21. elsif sunday ？（時間）
22. 時間+ 1 * 60 * 60 * 24
23. 他に
24. 時間
25. 終わり
26. 終わり
28. def saturday ？（時間）
29. time.strftime（ "％a" ）== "土"
30. 終わり
32. def sunday ？（時間）
33. time.strftime（ "％a" ）== "Sun"
34. 終わり
36. def turnaround_in_seconds
37. @ターンアラウンド* 60 * 60 * 24
38. 終わり
40. def start_time
41. @purchased_at または Time .now
42. 終わり
44. def days_from_today
45. if @purchased_at
46. （（ Time .now-@ purchase_at.to_time）/ 60/60/24）.floor + 1
47. 他に
48. @ターンアラウンド+ 1
49. 終わり
50. 終わり
51. 終わり

わあ！ 3年前に書いたこのコードは完全ではありませんが、ほとんど理解できます。 そして、すべての作品は理にかなっています。 これは、リファクタリングの2つまたは3つの波の後です。これは、別の投稿で明らかにするかもしれません。 いずれにせよ、あなたはその考えを理解しています。 これは、Rubyの5行のメソッドに焦点を合わせているということです。 コードが明確であれば、簡単に編集できます。



Rubyのクリーンオブジェクトを取得するという考えは、Railsでも当てはまります。 このルートを見てください：

Copy Source | Copy HTML

1. ルート：to => 'dashboard＃index' 、：constraint => LoggedInConstraint

え？ LoggedInConstraint？

Copy Source | Copy HTML

1. クラス LoggedInConstraint
2. def self .matches？（リクエスト）
3. current_user
4. 終わり
5. 終わり

A.はい。 ルーティングポリシーを記述するオブジェクト。 いいね 検証の例もomgbloglolで恥知らずに盗まれました ：

Copy Source | Copy HTML

1. def SomeClass < ActiveRecord ::ベース
2. validate：category_id、：proper_category => true
3. 終わり
5. クラス ProperCategoryValidator <ActiveModel :: EachValidator
6. def validate_each （レコード、属性、値）
7. record.user.category_idsを除きます。 include ？（値）
8. 記録。 エラー .add属性、 「カテゴリが間違っています。」
9. 終わり
10. 終わり
11. 終わり

これは純粋なRubyクラスではありませんが、あなたはその考えを理解しています。



「スティーブ、Railsだけではない、嘘をついた！」と思うかもしれません。ええ、はい、実際、あなたは私を捕まえました。 しかし、決してクラスを壊さないというtrapにあなたを誘惑するように思われるRails特有の何かがあります。 たぶんlib /はそのようなゴミリポジトリのようです。 15分間の例にActiveRecordモデルのみが含まれている可能性があります。 おそらく、非Railsを開くよりも閉じたRailsアプリケーションの方が多い（注：私自身の意見だけです）ので、信頼できる良い例はあまりありません。 （Railsは企業向けのサイト開発によく使用されるため、私はこの考えを持っています。宝石？まさに？私のWebアプリケーション？それほどではありません。それでも、確認する統計がありません。）



一般的に、ドメインオブジェクトの取得は適切です。 テストを高速化し、コードを短くし、将来の変更を容易にします。 私はまだこれについて、特に「クイックテスト」について何か言いたいことがありますが、私はすでに投稿の可能な長さを使い果たしました。 次回まで！