要求開発では，多くのUMLのダイアグラムが使われており，オブジェクト指向ベースのクラス図なども出てきます。技術者/開発者として，おそらく最初に思う疑問は「オブジェクト指向とかUMLとか，こんな難しそうなものをユーザーが果たして理解できるのか？ 現場で使えるのか？ 得ができるのか？」といったことだと思います。 私も要求開発の可能性に気づいて，要求開発に取り組み始めたのですが，取り組みながらもぬぐい去れない疑問が，上記の内容でした。 この問題を整理していきたいと思います。ITをビジネスで活用するシーンを想像してみましょう。要求開発アライアンスでは，システム開発を大きく二つのフェーズに分けています。一つは，存在する要求やRFP（Request For Proposal）にしたがってシステム作る「システム開発」フェーズ。もう一つは，戦略からシステム化する要求を作り出す「要求開発」フェーズです（図1

Part1　プロジェクト開始前夜 「的場くん，弁当チェーンのA社は知ってるだろう？ 明日のヒアリングに同席してくれないか」――ある昼下がりの午後。平田マネージャが的場さんの席まで来て声をかけました。 的場さんは，都内の中堅ソフトハウスに勤めるソフトウエア・エンジニアです。Javaを中心とするWebアプリケーションの開発では，ここ数年，様々な経験を積んでいます。ちょうど前のプロジェクトの切れ目だったこともあり，的場さんは平田マネージャの話に耳を傾けました。 「実は，A社の野崎システム部長から，新システム構築にあたって最近の技術動向，特にオブジェクト指向開発について話を聞かせてほしいと言われているんだ」 「はあ」 「で，だったら，わが社の開発のエースをお連れしますよ，ということで君に白羽の矢が立ったわけだよ」 それを聞いて，的場さんの胸に不安が去来しました。平田マネージャは現場を離れて10年以

具体論に入る前に，まずオブジェクト指向分析/設計とは何を意味するのかを定義しておきましょう＊1。 そもそも「分析」とはどういったことを指すのでしょうか。辞書を引いてみると，“ある事柄の内容・性質などを明らかにするため，細かな要素に分けていくこと”とあります。オブジェクト指向分析を適用する場面で明らかにしたい事柄とは，どのようなシステムを作らなければならないのかということです。つまり，オブジェクト指向分析とは，“どのようなシステムを作らなければならないのかを，オブジェクトという要素を使って解明すること”ということになります。これに対しオブジェクト指向設計とは，“分析によって明らかにしたシステムの実現手段を，オブジェクトという単位を使って明確にすること”となります。 両者の違いがイメージできたでしょうか。では以降は，具体的なサンプルに基づいてオブジェクト指向分析/設計の仕方を見ていきましょう。

2006年12月05日05:30 カテゴリLightweight Languages perl - 勝手に添削 - 条件分岐 というわけで、ひさかたぶりの勝手に添削のコーナーは、こちら。 CodeZine：Perlで作るモバイルサイトのコツ：第5回 （モバイル, XHTML, Perl） 多少長い判別となってしまいましたので用途に合わせて関数化してもよいでしょう。 さらにすっきりとロジックを書き出す方法がいくつもあります。 use HTTP::MobileAgent; my $agent = HTTP::MobileAgent->new; if ($agent->is_docomo){ if ($agent->is_foma){ # XHTML対応 } } elsif ($agent->is_ezweb){ if ($agent->is_win){ # XHTML対応 } } elsif

矢沢久雄のソフトウエア芸人の部屋 : 【第3回】 このごろオブジェクト指向セミナーの人気が高まっています　より。 正直、あまり残念がる必要はないと思います。ケイのオブジェクト指向とストラウストラップのオブジェクト指向は、同じ「オブジェクト指向」を称してはいるものの、その視点や立ち位置はぜんぜん違うものですから…。むしろ合点がいったらコワイくらいです。ｗ 現在主流の後者のオブジェクト指向の立場（カプセル化、すなわち“データ型”の設計を重視…）の考え方では「プログラムは、処理とデータからできている」で十分で、処理の動的な呼び出しをメッセージングと解釈するかどうかはその人の好み次第…というより、本来は無用のものです。むしろメッセージングなどというものは徹底的に排除して考える習慣をつけたほうが、ずっとその本質（抽象データ型とは何で、それをクラスで実装するメリットは何か…）にたどり着きやすいと思いま

Part3では，もはやオブジェクト指向開発では欠かせない存在となったソフトウエア・パターンについて解説しましょう。デザインパターンに代表される様々なソフトウエア・パターンを活用して，熟練者の経験を盗み，オブジェクト指向開発を円滑に進める術を習得してください。 ソフトウエア・パターンの全貌 皆さんは誰かが書いたプログラムを眺めていて，どこかで見たようなソフトウエア設計やコードに出くわしたことがありませんか？ 「このクラスの役割はどこかで見たことあるなあ」とか「このコードは何度も自分で書いたことがあるぞ」といった感覚です。そのような既視感は，そのコードを書いた人が，皆さんと似たような状況で，繰り返し発生する問題を抱えて，似たような設計/実装を行ったからかもしれません。 ソフトウエア・パターン＊1は，このような繰り返されるソフトウエア設計を集めたものです。それも単に集めたのではなく，様々なソフト

最近になって、オブジェクト指向に関するセミナーの依頼をよく受けるようになりました。 部課長クラスを対象に、オブジェクト指向の全容を理解させてほしい（2時間コース） 中堅エンジニアを対象に、UMLを使った分析・設計技法を指導してほしい（2日間コース） 新人プログラマを対象に、オブジェクト指向らしいプログラミングスタイルを教えてほしい（5日間コース） など、対象者と内容は様々です。オブジェクト指向は、1970年代からある技法です。決して新しいわけではありません。それなのに、なぜ今になってオブジェクト指向が流行りだしたのでしょう？ この疑問に対する答えも含め、2時間コースのセミナーの概要を、Web上で再現させていただきます。 最初に、皆さんに質問します。オブジェクト指向とは、何でしょう？．．．「プログラムの部品化のことだ」「効率的にプログラムを作れる技法だ」「コストを削減できる技法だ」「大規模シ

関数型言語とオブジェクト指向は相容れない，という説をよく聞く。たしかに「オブジェクトは状態を持つ」「関数型プログラミングでは，できるだけ破壊的代入を行わない」とすれば，二つの概念は矛盾しているようにも思われる。また，技術的観点以外にも，「とかくシンプルさを好む多くの関数型言語プログラマが，何かと物事を複雑にする（と思われている）オブジェクト指向を嫌っている」という面があるかもしれない。 しかし，個人の好き嫌いはさておき，実際問題として，関数型言語とオブジェクト指向は大いに関係がある。むしろ，基礎理論については，ほとんど同じコミュニティの人たちが取り組んでいる，と言ってもいい。例えば，以下のような研究が，1980年代から現在に至るまで行われている。 関数型言語のモデルであるλ計算という体系において，オブジェクトを表現する研究（参考リンクなど） λ計算にならい，（プロトタイプベースの）オブジェ

JavaScriptは，きちんとしたオブジェクト指向言語であって，オブジェクトを利用した高度な開発が可能です。JavaやC++，.NET系のオブジェクト指向言語がオブジェクトの定義にクラスという概念を用いる「クラス・ベース」の考え方を採用しているのに対し，JavaScriptではひな型となるオブジェクトを元に独自の機能を付加するという「プロトタイプ・ベース」の考え方を採用している点が特徴です。 まず最初に，皆さんの誤解を解いておきましょう。それはJavaScriptは，きちんとしたオブジェクト指向言語だということです。オブジェクト指向言語と言えば，JavaやC++などが有名ですし，C#やVisual Basic 2005といった米Microsoftが開発した.NET系の言語もあります。しかしこれらの言語に比べてJavaScriptは，一段低い「Webブラウザで利用する簡易言語」といったイメ

2006年11月16日16:55 カテゴリLightweight Languages オブジェクトは難しくない。難しいのはクラス 大人だからオブジェクトは難しくなる。子供にとっては実はオブジェクトは自然で自明で簡単だ。 オブジェクト指向を正しく理解する：ITpro オブジェクト指向はしばしば，とっつきづらく難しい技術と言われます。その理由の一つには，対象とする分野が広く，それぞれに深みがあることが挙げられます。しかし，それ以上にこの技術を難しくしている落とし穴とも言うべき原因が二つあると筆者は考えています。それは比喩を乱用する説明の仕方の問題と，「もの中心」を意味するコンセプト自体の問題です。事実、オブジェクト指向というのは最初は子供向けだったのだ。 このことを、現在「オブジェクトとはなんぞや」という大人たちは忘れてしまっている。 それで、オブジェクトとは何か、といえば、「自分が何が出来る

オブジェクト指向はしばしば，とっつきづらく難しい技術と言われます。その理由の一つには，対象とする分野が広く，それぞれに深みがあることが挙げられます。しかし，それ以上にこの技術を難しくしている落とし穴とも言うべき原因が二つあると筆者は考えています。それは比喩を乱用する説明の仕方の問題と，「もの中心」を意味するコンセプト自体の問題です。 そこで本特集では，「オブジェクト指向という言葉をよく聞くけど，実際どんなものかよくわからない」という方のために，初心者/入門者が陥りやすい落とし穴を明確にしながら，オブジェクト指向の全体像を説明します。余計な先入観やまぎらわしいたとえ話に惑わされなければ，オブジェクト指向そのものはそれほど難しい技術ではないことを理解していただきたいと思います。なお，オブジェクト指向プログラミング，デザインパターン，分析/設計といった個々の技術については特集2以降でそれぞれ解説

2006年10月20日10:55 カテゴリLightweight Languages メモリー効率は所詮実装次第 そう。まさにこれを言いたかった訳です。 Kazuho@Cybozu Labs: re: javascript vs perl - オブジェクトのメモリー効率 言語仕様のメモリ効率性を考えるのにあたって、(メモリの潤沢な環境向けの) 特定の実装間の比較をしても意味がないと思います。実はこの場合でも(2)だけではなく(2)-(1)の結果を見ると、私の手元では defval js 3348 pl 2680 [FreeBSD] とperlの方がよいという結果が出ちゃいましたが、それはさておき、この場合でもPerlは以下の工夫を施すことによりさらにメモリー効率を上げることができます。 defval.pl2 #! /usr/bin/perl use strict; use warnings

2006年10月19日11:30 カテゴリLightweight Languages javascript - Prototypal Object Modelの落とし穴 「404 Blog Not Found:javascript - プロトタイプ的継承」とその続編「404 Blog Not Found:javascript - プロトタイプ的継承完全版」は、案の定反応すべきbloggersが然るべき反応をしてくれた。これをbloggingの魅力と言わずしてなんと呼ぼうか。 プリミティブ値でもプロトタイプ的継承: Days on the Moon 書き上げた後に元記事の続きが出ているのに気づいたが、方向性が違うようなのでそのまま掲載。 IT戦記 - 関数一発でプロトタイプチェーンに繋げて、オブジェクトをクローンする。でも、実際はあそこまで複雑に書かなくても、できると思います ^^; 感想は

最近、プロトタイプ的継承の話しが盛り上がっています。 http://blog.livedoor.jp/dankogai/archives/50662064.html http://labs.cybozu.co.jp/blog/kazuho/archives/2006/10/javascript_string.php http://blog.livedoor.jp/dankogai/archives/50662606.html 最終形がやたら複雑になっています でも、実際はあそこまで複雑に書かなくても、できると思います ^^; そう思う理由 P 関数は object 関数の中でローカルのものである。コンストラクタとして使える必要はない。なので、 Atomic な場合でも P は function(){} でいい。 method 関数では P.prototype のプロパティに関数が代入されて

2006年10月18日21:00 カテゴリLightweight Languages javascript - プロトタイプ的継承完全版 Kazuho@Cybozuさま、いつもありがとうございます。 Kazuho@Cybozu Labs: JavaScript の String 型を継承する 結論から言うと、String 型も継承っぽいことができます。こんな感じ。 おかげでプロトタイプ的継承モデルの完全版が出来ました。 AtomicなObjectを継承 これは、以下のように包括的に出来ます。 var Atomic = function(C){ var P = function(v){ this._v = v; }; P.prototype = new C; P.prototype.valueOf = function(){ return this._v.valueOf(); } P.pro