Rubyの5つの活用例
Rubyで何ができるのだろうと思ったことはないだろうか。まあ、可能性は無限大でしょうが、多少なりとも知られている事例についてお話しできれば幸いです。
バングメソッドを作り始める前に、このタイプのメソッドがいったい何なのか、どんな特徴があるのかを学んでおこう。まず、この種のメソッドには明確な定義がないという事実から始めましょう。簡単に言うと、bangメソッドは最後に感嘆符がついたメソッドです。
バンバン方式はある意味で危険な方式であり、その定義の最後にある感嘆符は、この方式を使用する際には用心するようにと告げている、という記述にしばしば出くわすかもしれない。それでは、このような方法に関して、具体的にどのような脅威があり、どのような特徴があるのだろうか?
この種のメソッドの最もポピュラーな特徴のひとつは、たいてい観客を変えるということだ。例としてmap!メソッドを見てみよう。ドキュメントによると、map! メソッドはselfの各要素に対して与えられたブロックを1回呼び出し、要素をブロックが返す値で置き換える。ブロックが与えられない場合は、代わりにEnumeratorが返される。
arry = [1, 2, 3, 4, 5]
arry.object_id => 280
arry.map!{|num| num**num } => [1, 4, 27, 256, 3125] です。
arry.map! => # [1, 4, 27, 256, 3125] です。
arry.object_id => 280
見ての通り、object_idは変更されていない。だから、このような方法を使うことの危険性は明らかだ。もし コード 変数arryを他の場所で使った場合、マップ!はそれを変更してしまう。その結果、プログラムが好ましくない動作をしたり、クラッシュしたりする可能性がある。
のオブジェクトがある。 ルビー 例えば、Integer、Float、Symbolクラスのインスタンスなど。を操作している間 プロジェクトまた、次のようないわゆるマジックコメントもある:
frozenstringliteral: true
このようなコメントが使用されているコードでString recipientを変更しようとすると、次のようなエラーになる:
'abc'.upcase!
FrozenError(凍結された文字列を変更できません)
興味深いことに、変更不可能なストリングを導入する計画があった。 ルビー3.0しかし この変更は行わないことに決定した.しかし、すべてのbangメソッドが受信者を変更するわけではないことを覚えておく必要があるため、特定のメソッドの場合にどのような危険が予想されるかを常にドキュメントで確認する必要がある。
これらのメソッドのもう一つの特徴は、多くのメソッドで例外が発生することである。そのようなメソッドの例がActiveRecord::FinderMethods#firstである!ドキュメントによると、first!メソッドはfirst!メソッドと同じだが、レコードが見つからなかった場合にActiveRecord::RecordNotFoundを発生させる。first!は引数を受け付けないことに注意してください。
ファイル activerecord/lib/activerecord/relation/findermethods.rb, 行 128
def first!
first || raiserecordnotfoundexception!
end
しかし、上で使われているActiveRecord::FinderMethods#firstメソッドは次のようになる:
ファイル activerecord/lib/activerecord/relation/findermethods.rb, 行 116
def first(limit = nil)
checkreorderdeprecationはloaded?
if limit
findnthwithlimit(0、limit)
else
findnth 0
終了
終了
上記の例を見ると、前者を使うことの危険性がわかる。もしActiveRecord::FinderMethods#find! を使ってデータベースから適切なレコードが見つからなければ、ActiveRecord::RecordNotFoundが返され、プログラムが動かなくなる可能性があります。
しかし、これはメソッドの最後に感嘆符がなければ安全で、例外を発生させたり、受信者を変更したりしないという意味ではないことを忘れてはならない。
Ruby on Rails 6.0では、新しいメソッドのペアが導入された: ActiveRecord::Persistence::ClassMethods#insert_all
そして ActiveRecord::Persistence::ClassMethods#insert_all!
このうち最初の方法は、すでにある程度の危険性を示している。ドキュメントによればは、1つのSQL INSERT文で複数のレコードをデータベースに挿入します。モデルをインスタンス化したり、ActiveRecordのコールバックや検証をトリガすることはありません。しかしテーブルの一意インデックスに違反する行があると、ActiveRecord::RecordNotUniqueが発生します。この場合、行は挿入されません。つまり、これらのメソッドのうち最初のメソッドは、一意インデックスに違反するレコードを除くすべてのレコードを保存しますが、2番目の(より危険な)メソッドは例外を発生させ、データベースにレコードを保存しません。
末尾に感嘆符がついていなくても、使用するのは危険なメソッドが多い。例えば、ActiveRecord::FinderMethods#find。ドキュメントによると、要求されたIDのレコードが1つ以上見つからない場合、ActiveRecord::RecordNotFoundが発生する。
このメソッドの危険度はActiveRecord::FinderMethods#first!
受信者を変更する場合も同様である。例えば、Array.deleteは(ドキュメントにあるように)selfからobjectに等しいすべての項目を削除し、最後に削除された項目、または一致する項目が見つからない場合はnilを返します。
a = [1, 2, 3, 4, 5]
a.object_id #=> 320
a.delete(2) #=> 2
a #=> [1、3、4、5]。
a.delete(6) #=> nil
a.object_id #=> 320
オブジェクトが変更されたことがはっきりとわかる。この2つのメソッドに共通しているのは、感嘆符に相当するものがないということです。したがって、もし私たちが作りたいメソッドが上で述べたような危険性を持つのであれば、すぐに最後に感嘆符をつける必要はありません。さらに、作りたいメソッドよりも危険性の低い同じ名前のメソッドがすでにある場合は、bangメソッドを作ることをお勧めします。
なぜこのような危険なメソッドを使うのかと思うかもしれない。利点のひとつは、たとえば、生成されるオブジェクトの数を減らすことでコードのパフォーマンスが向上することだ。 Railsのパフォーマンス向上については、こちらをご覧ください。.
例外の発生に関して言えば、危険なcreate!メソッドではなくcreate!メソッドを使うと、レコードがデータベースに書き込まれないため、アプリケーションのエラーを発見しにくい状況になる可能性があります。したがって、このメソッドに渡すパラメータが正しいことが確かならば、create!
結論は簡単で、次のようなものだ。このようなメソッドを慎重に使えば、コードのパフォーマンスと品質を向上させることができる。しかし、不適切な使用はコードの正常な実行を妨げる可能性があることを常に覚えておかなければならない。
独自の危険なメソッドを作りたい場合、ある決定プロセスを経なければならない。まず、作りたいメソッドと同じ名前で、より危険度の低いメソッドがすでにあるかどうかが問題になる。一方のメソッドが他方のメソッドと同等で、より危険度が高いというペアのメソッドを作ることも考えられる。
感嘆符のない対応するメソッドが存在しないのであれば、bangメソッドを作る意味はありません。オブジェクトを変更したり例外を発生させたりする危険なメソッドがあるのに、名前の最後に感嘆符がついていない。それに相当するものがないbangメソッドを作ると、あなたのコードを使うプログラマーを混乱させることになる。その人は、このメソッドの何が危険なのか、なぜ名前の最後に感嘆符をつけるに値するのかを言うことができないでしょう。
次に、どのような種類の危険について話しているのかを考える必要がある。上記の例から、最も一般的な危険の種類は、(コピーを作成する代わりに)オブジェクト自体を変更するか、例外を発生させることであると結論づけることができる。もちろん、これはルールではなく、RubyやRuby on Railsで定義されているメソッドを分析した結果です。例えば、メソッドペアの実装を考えてみよう。 感嘆符 はそのレコードをデータベースに保存するが、感嘆符のついたメソッドはこのレコードの検証をスキップする。この場合、このようなメソッドを使うことの潜在的な危険性がどこにあるかは明らかである。
バングメソッドに関する知識をまとめると、次のような結論になる。 脅威が少ない
感嘆符のないメソッドでは、感嘆符のあるメソッドが危険なアクションを実行する。
結論から言えば、以下のコンセプトを理解することだ。 バングメソッド で ルビー ソフトウェア開発 は、あなたのコーディング・スキルを大幅に向上させ、コードベースをより明確にすることができる。 バングメソッド名前の最後に感嘆符が付いたものは、メソッドの破壊的なバージョン、あるいは潜在的に危険なバージョンを示す。慣例では カウンターパート このメソッドは、別個のコピーを作成することなく、オブジェクトを直接変更することができるので、注意して使用する必要があります。これは、変更可能なオブジェクトを扱う場合や、パフォーマンスの最適化が懸念される場合に特に有用です。しかし、bangメソッドを使うときには注意が必要です。適切に扱わないと、意図しない結果をもたらす可能性があるからです。また、すべてのメソッドに バングバージョンそして、その存在はケースバイケースで評価されるべきである。いつ、どのようにbangメソッドを作成するかの知識があれば、この強力なツールを効果的に使いこなし、特定の要件を満たすクリーンで効率的なコードを書くことができます。