古典的オブザーバパターンをいまさら基礎からみる【デザインパターン】 - Qiita
はじめに 色々なサイトに散らばっている情報を整理しただけ。一部Unityぽい。 Rx流行ってるけど、そもそも根底のオブザーバパターンを理解しよう。 オブザーバパターンを使うと何が嬉しいのか？ Observer側もObservable側も相手のクラスの内部設計を把握しなくて良い。 「データが変更されたらUIに反映する」というシナリオにおいて、 Model -> View という直接の依存関係を無くせる。 オブザーバパターンに頼らない場合 class Model { // データ変更時に呼ばれる void DataChanged() { // 変更後のデータを取得 var newData = this.GetData(); // ModelからViewを直接変更（MVC原則に違反しています！） FooView.Update(newData); } } GUIクラス（View）の追加が発生した時
Inversion of Control コンテナと Dependency Injection パターン
以下の文章は、Martin Fowler の「Inversion of Control Containers and the Dependency Injection pattern」を、かくたにが翻訳したものです。原著者の許可を得て翻訳・公開しています。 翻訳にあたっては、kdmsnr さんにご協力をいただきました。ありがとうございます。公開後の改訂履歴を記事の最後に記述しています。 Java コミュニティでは軽量コンテナが花盛りである。 軽量コンテナは、異なるプロジェクトのコンポーネントをひとまとまりのアプリケーションとして組み立てることを支援する。 このようなコンテナの根底には、コンポーネントの結び付け方についての共通したパターンがある。 そのパターンのコンセプトは「Inversion of Control(制御の反転)」と、まことに包括的な名前で呼ばれている。 本記事では、このパタ
混乱しがちなサービスという概念について - かとじゅんの技術日誌
社内でサービスがよくわからないという話になったので、考察を少しまとめておきます。 過去のエントリでも以下のように触れましたが、もう少しかみ砕いてみよう。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に"サービス"って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用可能にするためのものです。後者はドメインの知識を表している振る舞いです。これはのちほど詳しく説明します。 まぁこのあたりは具体例がないと理解しがたいですが、レイヤーの違いによって責務が異なるという感じです。DDDのサービスの章では、サービスには、アプリケーション層、ドメイン層、インフラストラクチャ層と、複数のレイヤーに存在すると言及されていま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
