この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ネストの深いプログラムを書くとき、 プログラム全体で共有したいオブジェクトをどうやって引き回すかというのはいつも悩む問題です。 グローバル変数 小さなプログラムの場合は雑にグローバル変数に入れてしまうのも悪くはないですが、 プログラムが大きくなるにつれ、このやりかたはつらくなります。 シングルトン シングルトンは基本的にはグローバル変数と同じことです。 ただしファクトリ関数をうまく使えばグローバル変数をそのままつかうより柔軟な取り回しが可能になるかもしれませんが。 グローバル変数にせよシングルトンにせよプログラム全体で状態を共有しますが
Game Programming PatternsDesign Patterns Revisited You can’t throw a rock at a computer without hitting an application built using the Model-View-Controller architecture, and underlying that is the Observer pattern. Observer is so pervasive that Java put it in its core library (java.util.Observer) and C# baked it right into the language (the event keyword). Observer is one of the most widely used
本エントリーでは次の点を整理したいと思います。 ServiceLocatorパターンとは何か？ Dependency Injection（以降DI）パターンとは何か？ DI Containerとは何か？ これらを使うと何がうれしいのか？ ServiceLocatorとDI何が違うのか？ ServiceLocatorとDIどちらを使うべきか？ はじめに 問題点 利用箇所の結合度をさげる 生成箇所の結合度をさげる ServiceLocatorパターン Dependency Injectionパターンを使う Dependency Injection Container ServiceLocatorとDependency Injection いずれを利用すべきか？ 本来不要であるServiceLocatorへの依存が発生してしまう 依存関係が分かりにくくなる テストが困難になる はじめに さて現代
Hey, Game Developer! Do you struggle to make your code hang together into a cohesive whole? Find it harder to make changes as your codebase grows? Feel like your game is a giant hairball where everything is intertwined with everything else? Wonder if and how design patterns apply to games? Hear things like “cache coherency” and “object pools”, but don’t know how to use them to make your game faste
ポリモーフィズム（サブクラスによる切り替え、抽象化） ここに分類されるのは、オブジェクト指向の第３原則、ポリモーフィズムを使用したパターンです。ポリモーフィズムを使用すると、動的に使用するクラスを切り替えることができます。＜参照＞ 他に分類されているものでも、ポリモーフィズムが重要な位置を占めているものもありますが、ここではそれしか使われていないものを扱います。 ただデザインパターン全体を通して強調されているのは、インターフェースでプログラミングするということです。実装への依存をなくし、そうすることによって設計の骨組みを明らかにするのです。 Template 次のようなメソッドがあった場合に、処理Bのところを条件によって変えたい場合があるとします。 class Hogehoge { void doit() { ... 処理A ... ... 処理B ... ... 処理C ... } }
問題一貫した方法でビジネスコンポーネントおよびサービスを透過的に検索する必要があります。フォースJNDI APIを使って、エンタープライズBeanやJMSコンポーネントといったビジネスコンポーネントや、データソースなどのサービスをルックアップして使用したいJ2EEアプリケーションクライアントのルックアップメカニズムの実装を集中化して、再利用できるようにしたいレジストリ実装のベンダー依存性をカプセル化して、その依存性と複雑さをクライアントが意識しないで済むようにしたいイニシャルコンテキストの生成やサービスルックアップに関するパフォーマンス上のオーバーヘッドを避けたいHandleオブジェクトを使って、以前にアクセスしたエンタープライズBeanインスタンスへの接続を再確立したい解決策Service Locatorを使用して、サービスとコンポーネントのルックアップを実装し、カプセル化します。Ser
2011-04-23 Akka の作者として益々注目を集めている Jonas Bonér が 2008年に書いた “Real-World Scala: Dependency Injection (DI)” を翻訳しました。翻訳の公開は本人より許諾済みです。翻訳の間違い等があれば遠慮なくご指摘ください。 2008年10月6日 Jonas Bonér 著 2011年4月22日 eed3si9n 訳 さて、実戦での Scala シリーズ第二弾の今回は、Scala を用いた Depenency Injection (DI) の実装をみていきたい。Scala は、備わっている言語機構だけを用いても何通りかの DI を実現できる非常に豊かでディープな言語だが、必要に応じて既存の Java DI フレームワークを使うこともできる。 Triental では、一つの戦略に落ち着くまで三つの異なる方法を試した
Recommendations on how to design and develop custom applications using the Microsoft platform Each patterns & practices offering contains a combination of written documentation and re-usable source code. Many also include a reference implementation. As the guidance is being developed it is reviewed and approved by internal Microsoft product teams and by external customers and partners. This produc
排他制御の実装パターンに Version Number パターンというものがある。 テーブルに INT 型の version_no というカラムを用意する。 UPDATE 時に version_no をインクリメントする。 UPDATE 時の WHERE 条件に version_no を追加する。 UPDATE dept SET dept_no = ?, dept_name = ?, loc = ?, version_no = version_no + 1 WHERE id = ? AND version_no = ? statement = connection.prepareStatement(UPDATE_SQL); statement.setInt(1, dept.getDeptNo()); statement.setString(2, dept.getDeptName()); s
「リポジトリパターン」でドメインモデル内にリポジトリという概念でオブジェクトの保管庫を設けると大変楽になります。 リポジトリをドメインモデルに持ち込んだ後、必ず次に気なるのは、リポジトリへの追加・削除などの変更をコミットするのはいつか？ということです。 リポジトリにAを入れて、Bを入れて、Cを削除したらエラーになったのでAを入れる前に戻したいのに、Aを入れた後にコミットされてたら面倒ですね。 こういった一連の処理を一つの作業単位にまとめるのがUoWパターンです。（参考：ファウラーさんのUoW解説） 「モデルの状態を変化させる責任はハンドラに持たせる」でドメインモデルへ変更を加える処理を実行する責任をハンドラに集約させるルールにしました。この一番のメリットは、ドメインモデルへの変更度合いの作業単位（UoW）を定義できることでした。 例えば、もし、あるユースケースで１つの既存の商品を削除して、
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 実践的なパターン Unit of Work パターンと永続性の無視 Jeremy Miller 目次 Unit of Work パターン Unit of Work を使用する 永続性の無視 (Persistence Ignorance) データベースとは無関係にビジネス ロジックを実行できるか データベース モデルとは無関係にドメイン モデルを設計できるか ビジネス ロジックに対する永続化戦略の影響 Unit of Work に関するその他の考慮事項 2009 年 4 月号の MSDN マガジン (「永続化のパターン」) では、ある種のオブジェクト/リレーショナル マッピング (O/RM) テクノロジを使用し
この記事には複数の問題があります。改善やノートページでの議論にご協力ください。 出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。（2024年3月） ほとんどまたは完全に一つの出典に頼っています。（2024年3月） 独自研究が含まれているおそれがあります。（2024年3月） 出典検索?: "Command パターン" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL Command パターン（英: command pattern）は、オブジェクト指向プログラミングにおいて命令あるいは動作をオブジェクトで表現するデザインパターンの一種である。 リクエストのために必要な手続きとデータをCommandオブジェクトとしてカプセル化した上で取り回し[1]、必要に応じて実行（execut
以下の文章は、Martin Fowler の「Inversion of Control Containers and the Dependency Injection pattern」を、かくたにが翻訳したものです。原著者の許可を得て翻訳・公開しています。 翻訳にあたっては、kdmsnr さんにご協力をいただきました。ありがとうございます。公開後の改訂履歴を記事の最後に記述しています。 Java コミュニティでは軽量コンテナが花盛りである。 軽量コンテナは、異なるプロジェクトのコンポーネントをひとまとまりのアプリケーションとして組み立てることを支援する。 このようなコンテナの根底には、コンポーネントの結び付け方についての共通したパターンがある。 そのパターンのコンセプトは「Inversion of Control(制御の反転)」と、まことに包括的な名前で呼ばれている。 本記事では、このパタ
Strategy パターン（ストラテジー - ）は、コンピュータープログラミングの領域において、アルゴリズムを実行時に選択することができるデザインパターンである。 Strategyパターンはアルゴリズムを記述するサブルーチンへの参照をデータ構造の内部に保持する。このパターンの実現には、関数ポインタや関数オブジェクト、デリゲートのほか、オーソドックスなオブジェクト指向言語におけるポリモーフィズムと委譲、あるいはリフレクションによる動的ダック・タイピングなどが利用される。 このパターンは、関数が第一級オブジェクトである言語では暗黙のうちに使用されている。例として後述のPythonコード例を参照のこと。 Strategy パターンは、アプリケーションで使用されるアルゴリズムを動的に切り替える必要がある際に有用である。Strategy パターンはアルゴリズムのセットを定義する方法を提供し、これらを
この記事には複数の問題があります。改善やノートページでの議論にご協力ください。 出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。（2015年10月） 脚注による出典や参考文献の参照が不十分です。脚注を追加してください。（2021年8月） 出典検索?: "Observer パターン" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL この記事内にあるすべての画像は、ベクターイメージである SVG ファイルとして再作成されるべきです。これにはいくつかの利点があります。詳しくはWikipedia:SVGへの乗り換えを参照してください。この画像の SVG 形式がすでに利用可能である場合は、アップロードしてください。アップロード後、この画像にあるこのテンプレートを{{SVG版利用可能
Ryo Asai @ryoasai74 最近は自分としてはDDDブームだしGoFを勉強することは無かったから、今日くらいは勉強しなおして質問事項でも考えておこうか。スピーカーではないですが。 #javaja_gof 2011-04-24 21:52:19 Ryo Asai @ryoasai74 パターンという考えを最初に知ったのはやはり、GoFの本がきっかけではありましたね。最初はパターンといえば、GoF以外知りませんでしたし。最初はJava Unleashedなどの電話帳みたいな英語の本のサンプルで知ったのがきっかけだったと思う。#javaja_gof 2011-04-24 21:56:04 Ryo Asai @ryoasai74 GoFのパターンはサンプルにあるワープロアプリケーションのように、どちらかというとGUIやコンパイラなどの複雑なプログラムで威力を発揮するものと思っていました
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
