Value Object ： シンプルで小型のオブジェクトに目覚めた経緯 | システム設計日記
Value Objects パターンが出てくる本。 ・ドメイン駆動設計(DDD) by エバンス ・PoEAA by ファウラー ・実装パターン by ベック。 三人とも、Value Object 、つまり、シンプルで小型で不変型の値オブジェクトを使うのが、設計・実装の良い習慣だといっている。 自分たちのプロジェクトでも、だいぶ Value Object パターンを普通に実践するようになった。 良い習慣になってきている感じ。 そこにいたるまでの経緯を簡単にまとめてみます。 出発点 こんな感じだった。 class Cstmr { private int id; private String nm1 ; private String nm2 ; private String zcd ; private String tdfk ; private String cty ; // こんな感じで、フ
Value Object（バリューオブジェクト） - Strategic Choice
師曰く数学的な値のように振る舞うオブジェクトを作成しなさい。どういうこと？変化する状態の入れ物ではなく、整数のように振る舞うオブジェクトのことです。数学の世界では、「1」に「1」を足しても、「1」自身が変更される訳ではなく、新たに「2」という数字が作成されます。プログラミングでこれを表現するのが「Value Object」になります。よって、「Value Object」は不変オブジェクト（Immutable）です。Javaのプリミティブはこの数学世界の住人で、そのラッパー（やStringは）はまさに「Value Object」と言えます。どうして？オブジェクトには大きく2種類、状態が変化する「状態型」と、変化しない「値型 *1」があります。値型を実現するのが「Value Object」パターンです。状態型の方が一般的ですが、状態を持つが故に「呼び出し順序」が重要になってしまっています。そし
グーグルが構築した大規模システムの現実、そしてデザインパターン（1）～MapReduce編
グーグルが「Evolution and Future Directions of Large-Scale Storage and Computation Systems at Google」（グーグルにおける、大規模ストレージとコンピュテーションの進化と将来の方向性）という講演を、6月に行われたACM（米国計算機学会）主催のクラウドコンピューティングのシンポジウム「ACM Symposium on Cloud Computing 2010」で行っています。 グーグルはどのようにして大規模分散システムを構築してきたのか、そして、そこからどのようなことを学んだのかが語られていますし、後半では大規模分散システムのデザインパターンという、非常に興味深いノウハウも公開している、非常に情報量の多い講演です。 その講演の内容を、全部で4つの記事、MapReduce編、BigTable編、教訓編、デザイン
Webサービスの設計：Webの状態遷移図の描き方 - 檜山正幸のキマイラ飼育記 (はてなBlog)
前置きも書いたことだし、実質的な話を進めましょう。 以前の2つの記事をザッと読んでおいて欲しいのですが、ホントに大事なところはこのエントリー内でも繰り返します。 Webサービスを設計するための単純明快な方法 Webサービスの設計： ハイパーオブジェクトとトリガー 内容： 画面遷移とはクライアント側の状態遷移のこと アクションが起動して結果を返すまで ハイパーオブジェクトとしての状態 アクションノードの内部構造 リクエスト辺と内部辺の切断 ログイン処理の例 状態遷移をモジュールにする 状態遷移モジュールの意義 画面遷移とはクライアント側の状態遷移のこと ここで状態遷移と呼ぶのは、Webクライアント（典型的な例はブラウザ）の状態遷移のことです。サーバー側の状態（リソース状態）は、今は考えないので注意してください。クライアント側の状態をアプリケーション状態と呼ぶこともあります（あんまり適切な用語
ダックタイピング - Strategic Choice
アヒルのように振る舞えば、それはアヒルである。どういうこと？クラスの継承関係とは独立してポリモーフィズムを行う仕組みで、オブジェクトが同じ名前のメソッドを持っているかどうかでポリモーフィズムを実現する言語の仕組みことです。どうして？継承は便利ですが、問題点もあります。親クラスを後から修正すると、子クラスに影響が波及し、正しく動作しなくなることがある。継承関係にないオブジェクトを、差分プログラミングのためだけに無理やり親子関係に設計してしまい、後に整合が取れなくなる。よって、最近のプログラミング言語では、無理な継承関係を構築せずとも、ポリモーフィズムを行う仕組みが用意されています。どうすれば？ダックタイピングが実現されている言語では、あるメソッドが定義されているかどうかの判断を、実行時にオブジェクトに問い合わせることで行います。そのため、ポリモーフィズムの実現に抽象インターフェイスは必要あり
WebMVCにおいては、View=Presentation+Seriarizationではないかという話 - monjudoh’s diary
この辺の話をしててちょっとインスピレーションが湧いたんだが、 GUIのMVCではなく、いわゆるWebMVCにおいては、 View=Presentation+Serialization なのではないだろうか? Presentationは何かっていうと人間が見る用で、 Serializationは何らかのプログラムでデータを使うので受け渡す用だと思う。 JSONとかXMLを返すAPIを作ったら、それを受けた側のプログラムでデシリアライズして、 何か処理したりするよね。そういうの。 で、なんで、Presentation or Serializationじゃないのかっていうと、 form生成ってSerializationの要素をかなり強く持ってるんじゃないかって思ったのだ。 極端な例を挙げると、modelからhiddenフィールドのみのformを生成して、 そのformをsubmitしたのを受け取
Webサービスを設計するための単純明快な方法 - 檜山正幸のキマイラ飼育記 (はてなBlog)
「Webサイト」、「Webアプリケーション」、「Webサービス」、「Web API」などの用語の区別はそれほど明確でもないし、きっちり区別して使うのもめんどくさいので、ここでは、これらを総称してWebサービスと呼んでしまうことにします。 山本陽平さんは、その著書『Webを支える技術』のなかで、人間がブラウザを使って利用するWebサイトとプログラム向けのWeb APIを区別すべきではないと述べています。この点は僕もまったく同感・同意です。 人間が相手となると、視覚的な効果や装飾、JavaScriptを使った操作性などにフォーカスが向けられ、Web APIとはまったく別物のような印象を与えます。しかし、各ページが持つべき情報やページ遷移の有向グラフ構造などは、相手が人間でもプログラムでも同じだと思うのです。そんな事情で、Webページの機能的／情報的なエッセンスを表現したHTML文書をクリーンH
e2wmについて考えたこと（調査や要件定義など） - 技術日記＠kiwanami
ツールを作るのも好き。昔からツールを作って満足して、そもそもの目的が達成できないタイプ。 はじめに この記事では、e2wm.elがなんでこんなUIになっているかを説明します。UIにはストーリーが重要だと思っていて、e2wm.elについて考えたことをまとめたいと思います。また、e2wm.elやこの記事をきっかけに、Emacsに限らず、今後のIDEの開発の貢献に役立てるといいなと思っています。 あんまりうまく使い分けできていませんが、名称について。 e2wm 仕組みや仕様を指すとき e2wm.el 今回の実装を指すとき あらすじ 画面が広くなって、なぜかEmacsが使いにくくなった そこで他のIDE、アプリなどのUIを調査してみた プログラマ（自分）の業務分析して要件を考えた 最初の実装のゴールを定義した 図の一覧@Cacoo (2010/07/03追記) Emacsと画面のサイズの変化 きっ
第28回 フォーム送信とブラウザ・ボタンと使い勝手（前編）～PRGパターンをご存じですか
皆さん，こんにちは。筆者は先日，アメリカはシリコンバレーに出張に行ってきまして，行きの飛行機の中で映画，ダイハード4.0を観ました。この映画，「4.0」という邦題もなかなかいい感じ（原題は「Live Free or Die Hard」）なのですが，題材はサイバーテロで，「ハッカー」がたくさん出てきます。Nokiaのスマートフォンを使ったり，新しさは随所にあるものの，どこかに侵入に成功するとでっかく「Access Granted」という緑色の文字が出てきたりして，この連載の第15回で取り上げたような，映画における古風なハッカーの表現手法がきちんと守られていてよかったです。 とは言っても，映画自体はテンポのいいアクションと，何人もの悪者が登場して，それぞれの悪者に対するムカツキ度が最大値に達したころにやっつけられるタイミングの良さで，かなりおもしろかったです。古風なハッカーの表現方法が知りたい
blog.8-p.info: Framework Design Guidelines を (半分まで) 読んだ
Posted at 2010/06/12 12:46, Modified at 2010/06/12 12:46 Microsoft の人々が .NET のライブラリを作る際にこんなことを考えて作ったんですよ、という "Framework Design Guidelines" (邦訳も『.NETのクラスライブリ設計』という名前で出ている) という本があり、それをずっと読んでいる。やっと半分まで来たんだけど、ここまででも十分に良い本だった。 最初 (1.1.4 にある Chris Sells の注) から Please don't innovate in library design. Make the API to your library as boring as possible. You want the functionality to be interesting, not th
Unix思想 - Strategic Choice
Unix思想とは、Unix文化が伝承している、優れた設計やプログラミングを行うための、実践的で経験に根付いた「技」のことです。Unix哲学とも呼ばれています。ただ、それらは公式的なメソッドや標準のなかではなく、「ことば」にならない半分無意識の知識のなかにありました。いわゆる形式知ではなく暗黙知であったこの「知」を、エリック・レイモンドさんが書籍「The Art of UNIX Programming」で17個の原則としてまとめてくれています。プログラミング・設計の際の「心がけ」として自分にインストールすべく、写経します。一覧モジュール化の原則明確性の原則組み立て部品の原則分離の原則単純性の原則倹約の原則透明性の原則安定性の原則表現性の原則驚き最小の原則沈黙の原則修復の原則経済性の原則生成の原則最適化の原則多様性の原則拡張性の原則Unix思想のまとめ参考The Art of UNIX Pro
SQLが苦手なオブジェクト指向屋さん - kなんとかの日記
炎上したのでまとめ (ベンチャー社長で技術者で) なんか炎上してるらしんだけど、なぜ炎上するのかわからない。ごく当たり前のことを言っているようにしか見えないのに、なぜあんなにアンチが湧くのか理解に苦しむ。ちっぽけなプライドの問題？ 2．SQLはオブジェクト指向言語の数十倍の効率 オブジェクト指向言語を使い切るのと、全部staticで宣言してしまうような使い方と比べても、効率は数十％も変わらない。 SQLとオブジェクト指向言語を比べたら、数百〜数千％の差が付く。 炎上したのでまとめ：ベンチャー社長で技術者で：エンジニアライフ まあ、そうだよね。SQLでできることはSQLでやったほうが高速 (例外もあるだろうけど少数)。 スクリプト言語とJavaとの速度差なんて、下手なSQLひとつで吹っ飛んでしまう。そういうのを経験すると、SQLがいかに重要かが身に染みてわかるし、ほかにも「言語の速度 !=
炎上したのでまとめ：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 炎上したので、論点を整理しておく。 1．業務系では効率がトレードオフできない必要条件 業務系の職務では、「効率を求めること」がトレードオフしてはいけない必要条件です（十分条件ではない）。医者でいうならば、「命・健康」と同じ、トレードオフしてはいけない必要条件です。 効率が必要条件にならない職業もあるけれど混同してはいけない。 2．SQLはオブジェクト指向言語の数十倍の効率 オブジェクト指向言語を使い切るのと、全部staticで宣言してしまうような使い方と比べても、効率は数十％も変わらない。 SQLとオブジェクト指向言語を比べたら、数百～数千％の差が付く。 言語や手法を考えるとき、慣れてない人はできないから無限大の工数が掛かる。ですから、できない人を対象に比べても
POSAのデザインパターン - Strategic Choice
書籍「ソフトウェアアーキテクチャ ― ソフトウェア開発のためのパターン体系（POSA : PATTERN-ORIENTED SOFTWARE ARCHITECTURE）」の「第3章 デザインパターン」で紹介されているパターン。デザインパターン一覧構造分割 Whole-Part作業の組織化 Master-Slaveアクセス制御 ProxyマネジメントCommand ProcessorView Handler通信 Forwarder-ReceiverClient-Dispacher-ServerPublisher-SubscriberAppendixPOSAのデザインパターン相互関連参考ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系作者: F.ブッシュマン,H.ローネルト,M.スタル,R.ムニエ,P.ゾンメルラード,Frank Buschmann,Hans Rohnert,M
アスペクト指向の基礎とさまざまな実装
2年ほど前から耳にするようになった「アスペクト指向」も最近ようやく広まってきた。この連載では「アスペクト指向とは何か？」というところから始め、AspectJやJBossAOPなどを用いたAOPの実装を紹介していく。 関心事の分離とは？ アスペクト指向の話には必ずといっていいほど「SOC」という言葉が登場する。このSOCは「Separation Of Concerns」の略であり、一般的には「関心事の分離」と訳されている。アスペクト指向を理解するためには「SOC」の概念を理解することが重要である。ここで、「また新しい3文字略語か」と顔をしかめて記事を読むのをやめてしまう読者がおられるかもしれないが、少し待ってほしい。このSOCは決して新しいキーワードなどではない。SOCとは、1960年代から1970年代にかけてのソフトウェア工学の黎明（れいめい）期に活躍し、「構造化プログラミング」を提唱した
DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticism
この記事はartima developerに掲載されている、Trygve Reenskaug氏とJames O. Coplien氏による記事「The DCI Architecture: A New Vision of Object-Oriented Programming」を、著作権者であるBill Bennrs氏の許可を得て翻訳したものです。本文内の図の著作権はArtima, Inc.に帰属します。（原文公開日：2009年3月20日） 要約 オブジェクト指向プログラミングはプログラマとエンドユーザの視点をコンピュータコードにおいて統一するものと考えられていた。この恩恵はユーザビリティとプログラムの分かりやすさの両面にわたる。しかし、オブジェクトは構造をとらえるのに長けている一方で、システムの動作をとらえることができていない。DCIはエンドユーザのロールに関する認識モデルとロール間の関係を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google App Engine Anti Patterns
中規模向けJS設計
ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系
Redditで学んだ7つのこと
