モデルに書いていたメソッドをPOROに切り出してみた！

PORO Ruby Ruby on Rails

はじめに

この記事は新しい技術にチャレンジし続けるpalanのアドベントカレンダーDay9の記事です！

昨日は「社内のFigma勉強会について紹介します！」についての記事でした。

社内のFigma勉強会について紹介します！

今回はモデルに書いたメソッドをPOROに切り出してみた話をします！

背景

今回のテーマの背景に、scriptタグに構造化データを動的に埋め込みたいという実装がありました。構造化テーマとは、検索エンジンがページの内容を理解しやすくするためのもので、ハッシュをjson形式に変換したものをscriptタグに埋め込むことで認識されます。構造化データの一部を示したものが以下になります。

この記事では一例として以下の構造化データが本の情報を表しているという仮定のもと、記述していきます。そのため、以下の構造化データはbooks/showなどで表示されるものと考えていただければと思います！

books/1の構造化データ


{ '@context': 'http://schema.org/',
  '@type': 'Book',
  'title': 'id1の本',
  'description':  'めっちゃ面白い'
  'value':  1
}

さて、これをデータに応じて動的に変更してscriptタグに埋め込もうとした時に、対応するメソッドをどこに書こうかと考えることになりました。

１、helperを使う

まずはviewに埋め込むものだしとりあえずhelperに書こう！と思い以下のようhelperに書いてみました。

books_helper.rb


def make_book_structured_data(book)
  { '@context': 'http://schema.org/',
    '@type': 'Book',
    'title': book.title,
    'description':  book.description,
    'value':  book.id
  }.to_json
end

こちらですが、もちろん問題なく表示されるものの一点問題がありました。それはテストが書きづらいことです。
正しく表示させないと検索エンジンに読み取ってもらえないためテストは必須なのですが、helperのテストはあまり一般的でもないためいい選択肢とは言えずhelperの選択肢は却下しました。

２、modelに書く

次の選択肢として、テストをしやすいという観点からやはりmodelにインスタンスメソッドとして書くのが無難かなと思い、modelに書いてみました。

book.rb


def make_book_structured_data
  { '@context': 'http://schema.org/',
    '@type': 'Book',
    'title': title,
    'description':  description,
    'value':  id
  }.to_json
end

この形だと確かにテストも書きやすいためここで終わりでも良さそうかなと思いましたが、この実装でも問題点はありました。それはモデルが大きくなりすぎてしまうことです。すでにメソッドが多く書かれている中で行数の長い上に（実際の構造化データはもっと行数が長い)、構造化データのための用途以外に使い道がないメソッドをモデルに書くことでbookモデルが大きくなってしまうのはあまり良いのではないのではないかと思い、別の方法を模索してみることにしました。

そこで選択肢としてPOROが浮かび上がってきました。

POROとは

POROとはPlain Old Ruby Objectの略で、Active Recordなどを継承していないクラスを作成するものになります。今回はPOROに構造化データの処理を切り出すことでテストの書きやすさは保ったまま先ほどまでの問題点を解消することにしました！以下が構造化データ用のクラスとメソッドをこのクラスに切り出したものになります。

book_structured_data.rb


class BookStructedData

  attr_reader :book

  def initialize( book:)
    @book = book
  end

  def make_json
    { '@context': 'http://schema.org/',
      '@type': 'Book',
      'title': title,
      'description':  description,
      'value':  id
     }.to_json
  end
end

これによって構造化データを呼び出したいときはBookStructedData.new(book: @book).make_jsonと書くことになります。

なお、テストに関しても以下のようにbook_structured_data_spec.rbを用意してモデルのインスタンスメソッドのテストと同じように書けば良いため、テストの書きやすさも確保できています。

book_structured_data_spec.rb


require 'rails_helper'

RSpec.describe BookStructedData, type: :model do

  describe '#make_json' do

    let!(:book) { create(:book, title: 'タイトル', description: '本文')  }
    let!(:structured_data_hash) { { '@context': 'http://schema.org/',
                                    '@type': 'Book',
                                    'title': 'タイトル',
                                    'description': '本文',
                                    'value': job.id } }.to_json

    subject { BookStructedData.new(book: @book).make_json }

    it do
      expect(subject).to eq structured_data_hash
    end
  end
end

以上のようにPOROにメソッドを切り出したことで、今回の実装で確保したいテストの書きやすさを担保しつつ、モデルが大きくなるという問題点も解決した実装を行うことができました！他にも方法はあるかと思いますが、今回は問題が解決したためこの実装で動的に構造化データを作成するタスクは終了しました。

社内の共有会でPOROの実装について話してみた

palanでは、週1回バックエンドエンジニアが集まり実装の相談や実装で試したことなどを持ち回りで話し合っております！そこで自分の持ち回りの会では、POROの実装について話させていただきました。

良さそうという話もある一方で、POROのデメリットもあるのではないか？という話が挙がってきました。

主に出たものとしては、POROの自由度が高いゆえに手を広げすぎるとよくないのではないかということです。POROはActive Recordを継承していない素のRubyのクラスのため、自由度が高く書けるゆえに何でもかんでも書いてしまうと悪影響が発生する可能性があります。

今回は構造化データを表示するためのみの目的で切り出したクラスのため、特に問題はなく、問題点について深く話し合うまでには至りませんでしたが、今後POROに切り出す際にはデメリットの意識は持とうということをバックエンドチームで共有できましたし、今後デメリットが出てきた場合には話し合う機会を作ろうということになったため、チームに良い影響や知見を与えることができたのではないかと思います！