サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
猫
hot-heart-cool-mind.hatenablog.com
業務システムの設計・開発を職業とする人々の間で、オブジェクト指向はいまだに一般的なものと受け止められていないように思える。しかし実際にやってみると、オブジェクト指向は業務システムにうまく馴染むし、システムの品質とメンテナンス性の改善につながる。 ==== オブジェクト指向の適用例 具体的な例で見てみよう。仕訳を作成して記帳するという、会計システムのもっとも基本的な処理を、Javaでオブジェクトを使って書いてみる: /** * 7月度の「帳簿(book)」を取得する。 */ 1: Book book = application.getBook("2006/7"); /** * 仕訳(JournalSlip)」を生成し、項目を設定する。 **/ 2: JournalSlip slip = book.createJournalSlip(); //仕訳日 3: slip.setJournalDat
「森の民(The Forest People) 」と「山の民(The Mountain People) 」の中で、人類学者 Colin Turnbull は、二つの社会を対照的に描きました。山岳地帯では、資源は乏しく、人々は常に飢餓の淵にいました。彼らが発達させた文化は、ぞっとするようなものでした。母親は、赤ん坊がなんとか生き延びられるかもしれぬ程度に成長するやいなや、捨て子たちの放浪集団にその子を遺棄しました。暴力、残虐行為、そして裏切りが、常態でした。 対照的に、森林地帯には豊かな資源がありました。ひとりの人が基礎的な必要を満たすには、一日に半時間も使えば十分でした。森林地帯の文化は、山岳地帯の文化を鏡に写したように逆になりました。大人たちは協力して子育てし、子供たちは、自分で自分の面倒をみる準備がすっかり整うまで、育てて貰い、愛されました。誰かが誤って誰かを殺してしまった場合(故意の
少し間が空いてしました。前回はアクション(IO操作の仕様書)とモナドが何とかつながったところで終わりました。 今回は両者の関係をもう少し緻密に検討してみましょう。 ==== アクションとモナド要件 (>>=)演算を備えただけでは「なりかけモナド」に過ぎま…
なぜ顧客は受入テストで仕様変更に気がつけるのか? ただ、ここで最近の興味の対象となるのは、「なぜ顧客は仕様を分かっている(だからテストでは指摘ができる)のにそれを完全に正確に伝えられないのだろう?」というもの。言い換えると、「顧客は欲しいシステムの必要な動作を本当は知っている。仕様を決めている時点でそれを正確に引き出すにはどんなサポートができるのだろう?」という疑問だ。 http://blog.hacklife.net/archives/50737557.html これに対して「本気度の違い」「ドキュメントで書けることの限界」「網羅性の違い」といった答えが、何人かの方から返されていて、僕もこれらの答えには基本的に賛成だということを言っておく。その上で、普段から感じている、もう少し「テクニカル」な要因について、ちょっと書いてみたい。 僕がなんらかの画面を設計して、ユーザーを招いて検証のための
4月も半ばを過ぎて、新入社員がプログラミング研修を受ける季節になったからだろうと思うが、オブジェクト指向談義が再燃している。ほとんど年中行事だ。 今年は、オブジェクト指向という用語をアラン・ケイの言った意味で使うのは「特権的」だという主張まで出たりした。 ギブソンが考えた「アフォーダンス」は、使い手と道具の関係性に関する概念だが、ノーマンはそれを「誤用」し、道具のデザインがもつ特性の話にした。現在では後者の方が広く受け入れられているように思うが、だからといって、アフォーダンスという用語はノーマンの意味で理解すべきだ、という話になるだろうか。 よくいって、アフォーダンスというひとつの言葉に対して2つの意味内容が「事実上」存在するということだ。そして、「本来の」アフォーダンスは、と言えば、ギブソンのそれを指すに決まっているではないか。 それは、特権云々の問題ではなく、アフォーダンスと言う言葉を
商売をする上で、ウケるということは絶対に必要です。ウケなければ何も売れません。 とはいえ、ウケるなら何でも構わずに売るということではないはずです。 モノであれサービスであれ思想であれ、本当に売る価値があると自身が思えるものを売る。その上で、その商品がウケる工夫、世間様に受け入れて頂くための方策を、寝ても覚めても考える。ウケること以前に、その商品に自分自身が価値を見出すことが大事なんです。 生半可に商売をわかった積りになっている人は、ここのところを理解していない。腑に落とせていない。だからすぐに、ウケそうか、売れそうか、という話をする。それが、商売人らしい、リアリスティックでオトナな態度だと思い込んでいる。まったくバカバカしいことです。 実際には逆です。 売れそうだからと思って、自分の思い入れがないモノを売ろうとしたとしましょう。それが売れればまあいい。お金や名声が得られますから満足感はある
オブジェクト指向には、もともとアラン・ケイが創案したメッセージ・パッシングのオブジェクト指向と、その後、抽象データ型から発展したオブジェクト指向の2つがあって、その2つは、プログラム言語の機構の面からは共通する要素も多いのだけどプログラミングに対するビジョンという点では相当に異なっている、という見方があります。 これに関しては、id:sumim さんが「二つのオブジェクト指向とそれぞれのメリット」という行き届いた論考を公開しておられて、僕などはそれを読んで頭を整理した口です。 その後、それを踏まえて自分なりに両者の違いを考えてツイートしましたが、言葉足らずな点もあったので、内容を整理するとともに加筆しました。 言語機構に惑わされるな この2つのオブジェクト指向は、実現する機構の面では似ています。オブジェクト指向の3要素として「カプセル化、継承、ポリモフィズム」があると言われますが、そうした
このところ、仕事の手が空いたときに、Haskell というプログラム言語を勉強しています。Haskellは僕がふだん使っているJavaなどとはかなり趣きが異なるので、 考えさせられる点が多く、気分転換にはぴったりです。 とはいえ、最初はさっぱり理解できない点もありました。「IOモナド」です。 Web上の色々な資料を読んでいるうちにだいたいのところは理解できたのですが、そうなってみると、今度は、 最初に読んだ何冊かの入門書やWeb記事でのIOモナドの説明の仕方が気になってきました。 こうした記事は、素人向けに易しくIOモナドを説明しようとして、その結果、かえって読者を煙に巻いてしまっている面があるんじゃないかと思います。 IOモナドは、Haskell の鬼門とか呼ばれているようですが、わかってみるとさほど難しいものではありません。であれば、僕自身がきわめて素人くさくIOモナドを理解した仕方を
ドメイン駆動設計に関して過去にお話しした際の発表資料やその他書いたものをまとめました。 PHPカンファレンス2015とその再演 2015年10月3日に開催された同カンファレンス内のPHPメンターズセミナー「モデルを設計せよ!―ドメイン駆動設計を超えて」が、ドメイン駆動設計に関して初めてお話しした機会でした。 ドメイン駆動設計に関してはその後も色々な表現でつぶやいたりしていますが、結局は、この時に発表した内容の変奏曲にすぎません。 PHP Mentors — PHPカンファレス2015...←山根さんによる参加記 ドメイン駆動設計 ~ユーザー、モデル、エンジニアの新たな関係~ from 啓 杉本 www.slideshare.net これは、ご出席の皆様からは結構ご評価を頂き、2回、内容を少しずつずらせながら再演しました。 再演 1:IT勉強宴会 IT勉強宴会の佐野さんから、PHPカンファレ
このページを最初にブックマークしてみませんか?
『Hot Heart, Cool Mind.』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く