ソシオメディアが独自に提供するUIデザインパターン集。これを使えばUI設計を効率化できます。
![ソシオメディア | UIデザインパターン](https://cdn-ak-scissors.b.st-hatena.com/image/square/49d830fc020446de280bd686d17ce59a737032af/height=288;version=1;width=512/https%3A%2F%2Fwww.sociomedia.co.jp%2Fassets%2Fimages%2Fsociomedia-logo-ogp-512.png)
AWSクラウドデザインパターンとは? AWSクラウドデザインパターン (AWS Cloud Design Pattern, 略してCDPと呼ぶ)とは、AWSクラウドを使ったシステムアーキテクチャ設計を行う際に発生する、典型的な問題とそれに対する解決策・設計方法を、分かりやすく分類して、ノウハウとして利用できるように整理したものである。 これまで多くのクラウドアーキテクト達が発見してきた、もしくは編み出しきた設計・運用のノウハウのうち、クラウド上で利用が可能なものをクラウドデザインのパターンという形式で一覧化し、暗黙知から形式知に変換したものであるといえる。 パターンの中には、クラウドでなくても実現できるもの、今まででも実現されていたものも含まれているが、クラウド上でも今まで通りのアーキテクチャが実現でき、かつクラウドを利用する事で、より安価にそしてより容易に実現できるものは、CDPとして収
DIコンテナとデザインパターン 2004.9.17 ひがやすを © Copyright The Seasar Project and others 2004. all rights reserved. Dependency Injectionパターン • インターフェースと実装の分離。 – コンポーネント同士はインターフェースを通じてのみ会話する。 – 実装を簡単に変えられるので、モックオブジェクトを使って簡単にテ ストができるので、テスタビリティが上がり品質が良くなる。 – 実装が出来上がってなくても、モックオブジェクトを使って開発を進 めることができ、無駄な待ち時間が生じない。 • コンポーネントの生成、依存関係の解決はコンテナが行う。 – 依存関係の解決とは、setterメソッドやコンストラクタなどを通じて、 あるコンポーネントに対して、依存関係のあるコンポーネントを設定 す
PofEAAのWikiです。Martin Fowler氏とAddison-Wesley Pub Coの許可を得て、 パターンカタログの翻訳を行っています。bliki_jaと同じくどなたでも参加可能ですので、是非参加してみてください ;-) ※このサイトは書籍の邦訳とは一切関係ありません。 ■ PofEAAのパターンカタログ and PofEAAのパターンカタログ(邦訳版)ここから読み始めるとよいでしょう。対応表もあります。 ■ 読書会 第12回の開催予定は未定です。 ■ PofEAA読書会メーリングリスト読書会に関する話題を扱っていますが、読者会への参加を強制するものではありません。興味のある方の参加は随時受け付けています。
デメテルの法則 (Law of Demeter, LoD) または最小知識の原則 (Principle of Least Knowledge) とは、ソフトウェアの設計、特にオブジェクト指向プログラムの設計におけるガイドラインである。 このガイドラインは1987年の末にかけてノースイースタン大学で作成された。簡潔に言うと「直接の友達とだけ話すこと」と要約できる。基本的な考え方は、任意のオブジェクトが自分以外(サブコンポーネント含む)の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 「デメテルの法則」という名前は、この法則がアダプティブプログラミングとアスペクト指向プログラミングに関する研究であるデメテルプロジェクトの成果であることに由来する。プロジェクト名は農業の女神であるデーメーテールにあやかっている。 オブジェクト指向プログラムにデメテルの法則を適用する場
言葉に直しながら読むと分かった気分になれるので自分用のメモがてら (*ノωノ) とりあえずの所感としては、色々なパターンが非常に重たく見える。 でも、重たく見えても中身をよくよく見れば普段愛用してる概念の固まりだったり。 絶対見せ方で失敗してるきがする > J2EE Intercepting Filter いわゆるServlet Containerの提供してるFilterな感じ。 説明的にもCoRできるように作れーって書いてあるし本当にまんまだ。 こういう概念が無かった時代はみんな if/else でがんばってたんだろうな。。。 (´・ω・`) 読み進めてたら戦略の項目でまさに ↑ な事が書いてあった (*ノωノ) ここら辺を見てると、AOPっていう概念はこういう所から生まれたのかなーという気がしてきますね。 Front Controller まんまStrutsかなー。 やろうとしてる事と
そんなこんなで続きー。 今日は7章を制覇(流し読み)するぞー (`・ω・´) Business Delegate Delegateって名前ついてるけど、Facadeの一種かなぁ。 どちらかというと分散ネットワーク上のどっかにいるFacadeを利用する際の、ローカル向けFacadeな感じがする。 ネットワーク例外をアプリケーション例外にしたい、とかってあたりもろにそうっぽぃ。 何かしようとするたびにRMI周りの例外のTryCatchとかやってたら発狂できるもんなぁ・・・ これを使う事でプレゼンテーション層と実際のビジネスロジックを実行するビジネス層(ネットワークのあっちにいるかも)なのと疎結合に出来るのと必要に応じてキャッシュする事でパフォーマンスの最適化が図れるのが一番のメリットかな。 Service Locator ものすっごいDIコンテナの先祖っぽい雰囲気がする! 責務的にはめちゃ大変
"Beautiful Develpment"(10/27 DevLOVE)の講演資料と原稿 はじめに 本日(10/27)、DevLOVE様主催で、"Beautiful Develoment"と題されたイベントが開催されました。これは「ドメイン駆動設計("DDD:Domain-Driven Design")」を題材に、入門から実践までを語り尽くすというコンセプトのものです。このイベントにおける講演のトップバッターとして、ドメイン駆動設計の根底にある基本的な考え方についてお話しさせて頂きましたので、講演資料と原稿を公開いたします*1。 スライドはこちら アジェンダは以下の通りです。 導入 オブジェクトとは? モデルとは? ドメイン駆動設計とは? まずは、ドメイン駆動設計のベースとなっている、「オブジェクト指向」や「モデル」について整理した上で、実際にドメイン駆動設計とはどういうものかを見ていき
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く