window.pipedriveLeadboosterConfig={です。 ベース:'leadbooster-chat.pipedrive.com'、 companyId:11580370, playbookUuid: '22236db1-6d50-40c4-b48f-8b11262155be', version: 2、 } ;(function () { var w = window もし (w.LeadBooster) {なら console.warn('LeadBooster already exists') } else { w.LeadBooster = { {. q: [], on: function (n, h) { this.q.push({ t: 'o', n: n, h: h }) }, trigger: 関数 (n) { { this.q.push({ t: 'o', n: n, h: h }) this.q.push({ t: 't', n: n }) }, } } })() Rubyソフトウェア開発:バングメソッドとその作成方法 - The Codest
The Codest
  • 会社概要
  • サービス
    • ソフトウェア開発
      • フロントエンド開発
      • バックエンド開発
    • Staff Augmentation
      • フロントエンド開発者
      • バックエンド開発者
      • データエンジニア
      • クラウドエンジニア
      • QAエンジニア
      • その他
    • アドバイザリー
      • 監査&コンサルティング
  • 産業
    • フィンテック&バンキング
    • E-commerce
    • アドテック
    • ヘルステック
    • 製造業
    • 物流
    • 自動車
    • アイオーティー
  • 価値
    • CEO
    • CTO
    • デリバリー・マネージャー
  • チーム
  • Case Studies
  • ノウハウ
    • ブログ
    • ミートアップ
    • ウェビナー
    • リソース
採用情報 連絡先
  • 会社概要
  • サービス
    • ソフトウェア開発
      • フロントエンド開発
      • バックエンド開発
    • Staff Augmentation
      • フロントエンド開発者
      • バックエンド開発者
      • データエンジニア
      • クラウドエンジニア
      • QAエンジニア
      • その他
    • アドバイザリー
      • 監査&コンサルティング
  • 価値
    • CEO
    • CTO
    • デリバリー・マネージャー
  • チーム
  • Case Studies
  • ノウハウ
    • ブログ
    • ミートアップ
    • ウェビナー
    • リソース
採用情報 連絡先
戻る矢印 戻る
2021-05-28
ソフトウェア開発

Rubyソフトウェア開発:バングメソッドとその作成方法

The Codest

ピョートル・コモロフスキ

Software Engineer

バングメソッドを作り始める前に、このタイプのメソッドがいったい何なのか、どんな特徴があるのかを学んでおこう。まず、この種のメソッドには明確な定義がないという事実から始めましょう。簡単に言うと、bangメソッドは最後に感嘆符がついたメソッドです。

バンバン方式はある意味で危険な方式であり、その定義の最後にある感嘆符は、この方式を使用する際には用心するようにと告げている、という記述にしばしば出くわすかもしれない。それでは、このような方法に関して、具体的にどのような脅威があり、どのような特徴があるのだろうか?

バング・メソッドの特徴

1.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メソッドが受信者を変更するわけではないことを覚えておく必要があるため、特定のメソッドの場合にどのような危険が予想されるかを常にドキュメントで確認する必要がある。

2.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番目の(より危険な)メソッドは例外を発生させ、データベースにレコードを保存しません。

3.bangメソッドには、感嘆符のない同等のメソッドがある。

末尾に感嘆符がついていなくても、使用するのは危険なメソッドが多い。例えば、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メソッドを作成するかの知識があれば、この強力なツールを効果的に使いこなし、特定の要件を満たすクリーンで効率的なコードを書くことができます。

関連記事

フィンテック

Rubyの5つの活用例

Rubyで何ができるのだろうと思ったことはないだろうか。まあ、可能性は無限大でしょうが、多少なりとも知られている事例についてお話しできれば幸いです。

The Codest
パヴェル・ムジンスキー Software Engineer
エンタープライズ&スケールアップ・ソリューション

強力で結束力のあるチーム作りのベストプラクティス

ソフトウェア開発を成功させるためには、コラボレーションが不可欠です。協力し合える強力なチームは、より良い成果を達成し、課題を克服することができる。コラボレーションを促進するには、努力、コミュニケーション、継続的な...

The Codest
クリスティアン・バルチャンスキー フロントエンドユニットリーダー
ソフトウェア開発

NextJSのデータフェッチ戦略

最近、NextJSはReactアプリケーションを作る方法として、ますます人気を集めています。確かに、NextJSがいくつかの異なるデータ取得戦略を提供していることが、大きな貢献をしています。

The Codest
パヴェル・リブチンスキ Software Engineer
ソフトウェア開発

最も人気のあるReactフックをさらに深く見る

何度もインタビューをする中で、経験豊富なプログラマーでさえ、フックの見分け方に問題を抱えていることに気づいた。そこで今回は

The Codest
パヴェル・リブチンスキ Software Engineer

ナレッジベースを購読して、IT部門の専門知識を常に最新の状態に保ちましょう。

    会社概要

    The Codest - ポーランドに技術拠点を持つ国際的なソフトウェア開発会社。

    イギリス - 本社

    • オフィス 303B, 182-184 High Street North E6 2JA
      イギリス、ロンドン

    ポーランド - ローカル・テック・ハブ

    • ファブリチュナ・オフィスパーク、アレハ
      ポコジュ18、31-564クラクフ
    • ブレイン・エンバシー, コンストルクトースカ
      11, 02-673 Warsaw, Poland

      The Codest

    • ホーム
    • 会社概要
    • サービス
    • Case Studies
    • ノウハウ
    • 採用情報
    • 辞書

      サービス

    • アドバイザリー
    • ソフトウェア開発
    • バックエンド開発
    • フロントエンド開発
    • Staff Augmentation
    • バックエンド開発者
    • クラウドエンジニア
    • データエンジニア
    • その他
    • QAエンジニア

      リソース

    • 外部ソフトウェア開発パートナーとの協力に関する事実と神話
    • 米国から欧州へ:アメリカの新興企業がヨーロッパへの移転を決断する理由
    • テックオフショア開発ハブの比較:テックオフショア ヨーロッパ(ポーランド)、ASEAN(フィリピン)、ユーラシア(トルコ)
    • CTOとCIOの課題は?
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • ウェブサイト利用規約

    著作権 © 2025 by The Codest。無断複写・転載を禁じます。

    jaJapanese
    en_USEnglish de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish arArabic it_ITItalian ko_KRKorean es_ESSpanish nl_NLDutch etEstonian elGreek jaJapanese