ソフトウェアの設計・開発で、OO:Object Oriented は、根本的な考え方の変化(パラダイムシフト)だと思う。
ソフトウェア開発の世界では、"Object Oriented" は、誰もが聞いたことがある言葉だと思うが、意味や使い方が、人によって、状況によって、ばらばらな、かなり不可思議な言葉でもある。
オブジェクト指向言語を使ったプログラミングの総称?
もし、Java , C#, PHP5 などをオブジェクト指向言語と呼べるなら、世の中には、オブジェクト指向プログラマがたくさんいるわけだ。
実感とはだいぶ違う。
分析や設計の考え方が オブジェクト指向じゃないのに、言語だけ、オブジェクト指向(風?)でもそれは、OOPとは言えないですよね。
UML でクラス図とか描くこと?
オブジェクト指向言語の話といっしょで、ツールや手段が、 OOAD 風でも、実際の分析や設計が、オブジェクト指向とは、とても呼べないものが多いのが現状。
(というか、そもそも、分析・設計をやっていない?)
オブジェクト指向の「分析」は、オブジェクトのモデリング(模型づくり)をすること。
オブジェクト指向の「設計」は、オブジェクトのモデル(模型)を、実装にマッピングするための、いろいろな意思決定、決め事をすること。
こんな感じだと思っている。
OO は、「オブジェクトのモデリング」が起点であり、また、オブジェクトモデルによって、設計・開発を駆動していくやり方。
オブジェクトモデリングの説明で、「実世界を抽象化して、実世界の模型を作ること」というのをどっかで見た。(あちこちで、似たようなことを読んだ記憶がある)
この説明がまちがっているとは思わないが、「抽象化」も、人や文脈によって、意味や使い方がばらばらな、不可思議な言葉なんで、この説明で、多くの人が、同じ理解をするとは思えない。
「実世界」もそうとう怪しい言葉。物理的に形があるもの、という印象が強すぎる気がする。
すくなくとも、エンタープライズアプリケーション( 事業用の業務システム)の世界では、伝票とか契約書という、物理的な実体ではなく、「申込」とか「契約」とか、そもそも、概念的な情報の扱いが中心課題。
「オブジェクト」を、実体のある「モノ(thing)」という感覚だと、業務アプリ開発で、オブジェクト指向的に取り組むのは、最初から無理なんだと思う。
私は、学生時代の専門は、英米文学。その影響だと思うけど、コンピュータ用語の「もともとの意味」「ITの世界以外での使い方」に、とても、興味がある。
興味があるというより、コンピュータ用語も、言葉のもともとの意味、IT世界以外での使われ方で、理解するのが、本筋だと思っている。
Object (オブジェクト) は、もともとの意味は、「標的」とか「関心の対象」。
Subject(主体)が、特に関心を持っている対象が、Object(客体)になる。
関心事でないものは、世の中に存在していても、それは、Object とは呼ばない。
関心事であれば、実体がなく、頭の中だけに存在している概念でも、それは、Object である。
つまり、オブジェクトのモデリングとは、「関心事」のモデリングだということ。
業務アプリのオブジェクトモデリングとは、業務の関心事体系の模型を作ること。
業務の関心事が整理されている模型なら、表現形式がクラス図であっても、業務の専門家には、わかりやすいはず。
線の記法など細かいことは別にして、
パッケージ名
パッケージ内のクラス名
全体の並び
が、業務の専門家が自分の担当業務の主たる関心事に見えるようになれば、それが、良いオブジェクトモデルだということ。
(よくできた業務マニュアルの目次のイメージ)
当たり前だけど、「業務の関心事体系」であるオブジェクトモデルには、ソフトウェア開発には必要になる技術的な概念(用語)は、まったく含まれない。
業務の関心事といっても、中間的な関心事と、最終的な関心事がある。
ユースケースで考えてみると、
◎最終的な関心事:ユースケースの結果、手に入る情報とか、状態。
●中間的な関心事:ユースケースの途中で、作業に必要な参照データなど。
に分けることができる。
オブジェクト指向は、「目的」指向だから、「最終的な結果」が、もっとも重要な関心事になる。
中間の関心事も、業務アプリには、必要だけど、最終的な目的(オブジェクト)に比べれば添え物。
ユースケースに登場するすべての関心事をオブジェクトとしてフラットに列挙するのは、アンチパターン。失敗作ですね。
オブジェクト指向は、関心事、それも最終の結果、つまり目的を中心に物事を把握・整理する手法であり考え方なんだと思います。
ドメインオブジェクトのモデリングでは、いつも、「最終目的であるドメインオブジェクト」を中心に、ものごとを、理解し、整理することが大切。
業務の目的(重要な関心事)は、基本的には、
その関心事を記録する
その関心事を通知する
の二つです。
記録や通知の詳細な属性のモデリングの前に、記録したいことは何か?、通知したいことは何か?、その一番の関心事に、名前を付けること、それが、業務ドメインのオブジェクトモデリングの基本中の基本。
これは、ジャングルや暗闇の中で、迷走する作業ではありません。
ユースケースの名前に、最初からその答えがあるんだから。
注文を受け付ける
発注する
予約する
キャンセルする
「注文」「発注」「予約」「キャンセル」
これが、ドメインの主たる関心事。だから、これがそのままドメインオブジェクトになる。
後は、この主たる関心事オブジェクトが、どんな情報を持っているべきか、そこにどんな業務ルール/業務知識があるか、に注目しながら、モデル(模型)を、育てていけばよい。
簡単でしょう?
ポイントは「主たる関心事」、業務の「目的」オブジェクトを、まず、発見し、関係者で共有すること。
ここができてしまえば、業務ドメインのオブジェクトモデリングは、8割がた、成功したも同然です。
初期の段階で、業務の主たる関心事をとらえそこね、登場する言葉が、なんでもかんでも、オブジェクトに見えてきてしまったら、完全に失敗パターン。
業務の主たる関心事は、単純だし、明確なものです。
多くの技術者が、それをとらえそこねているのが、業務アプリ開発の実情かもしれません。
そんな難しいことでは、ないんだけどなあ。
私は、Oriented ( 指向 )という言葉は好きではない。
これは、無理やりにある方向に、整列させる、という、強制的な印象が強い言葉。
あるいは、教会の祭壇は「東向」が決まり、など、思考停止している印象がある言葉。
なぜそっちに向かっているのか、向かうべきか、直観的に伝わりにくい。
目的を指向すべきだ、というのは正しい。
でも、それは、言われたから、そっちを向いているだけ、という感じがする。
力づくで、そっち向きにさせられている。
私は、「指向」より「志向」のほうが良いと思っている。
「志向」とは、人間が、ある思いをもって、そちらに向かっている、という主体的、自発的なエネルギーを感じさせることばです。
目的「指向」は、営業目標のノルマを強要されているサラリーマンのイメージ。
目的「志向」は、自らの向かう道を見定めて、力強く歩いている、自律した起業家やプロフェッショナルのイメージ。
ソフトウェア開発でも、ドメインオブジェクト(業務の関心事)を「指向」しなさい、では、良いソフトウェアは生み出せないと思っている。
業務の目的に、自分も主体的に参加して、その目的の達成のために、みんなと協力しようという、「目的志向」の個人が集まること。
チームの各メンバーが、チームの「目的(最終結果)」を、共有して、自ら、そこに向かって力強く歩くこと。
それが、Object Oriented 「目的志向」なソフトウェア開発なんだと思う。
ソフトウェア開発の世界では、"Object Oriented" は、誰もが聞いたことがある言葉だと思うが、意味や使い方が、人によって、状況によって、ばらばらな、かなり不可思議な言葉でもある。
OOP:オブジェクト指向プログラミング
オブジェクト指向言語を使ったプログラミングの総称?
もし、Java , C#, PHP5 などをオブジェクト指向言語と呼べるなら、世の中には、オブジェクト指向プログラマがたくさんいるわけだ。
実感とはだいぶ違う。
分析や設計の考え方が オブジェクト指向じゃないのに、言語だけ、オブジェクト指向(風?)でもそれは、OOPとは言えないですよね。
OOAD:オブジェクト指向分析設計
UML でクラス図とか描くこと?
オブジェクト指向言語の話といっしょで、ツールや手段が、 OOAD 風でも、実際の分析や設計が、オブジェクト指向とは、とても呼べないものが多いのが現状。
(というか、そもそも、分析・設計をやっていない?)
オブジェクト・モデリング
オブジェクト指向の「分析」は、オブジェクトのモデリング(模型づくり)をすること。
オブジェクト指向の「設計」は、オブジェクトのモデル(模型)を、実装にマッピングするための、いろいろな意思決定、決め事をすること。
こんな感じだと思っている。
OO は、「オブジェクトのモデリング」が起点であり、また、オブジェクトモデルによって、設計・開発を駆動していくやり方。
実世界を抽象化した「模型」?
オブジェクトモデリングの説明で、「実世界を抽象化して、実世界の模型を作ること」というのをどっかで見た。(あちこちで、似たようなことを読んだ記憶がある)
この説明がまちがっているとは思わないが、「抽象化」も、人や文脈によって、意味や使い方がばらばらな、不可思議な言葉なんで、この説明で、多くの人が、同じ理解をするとは思えない。
「実世界」もそうとう怪しい言葉。物理的に形があるもの、という印象が強すぎる気がする。
すくなくとも、エンタープライズアプリケーション( 事業用の業務システム)の世界では、伝票とか契約書という、物理的な実体ではなく、「申込」とか「契約」とか、そもそも、概念的な情報の扱いが中心課題。
「オブジェクト」を、実体のある「モノ(thing)」という感覚だと、業務アプリ開発で、オブジェクト指向的に取り組むのは、最初から無理なんだと思う。
「目的」指向
私は、学生時代の専門は、英米文学。その影響だと思うけど、コンピュータ用語の「もともとの意味」「ITの世界以外での使い方」に、とても、興味がある。
興味があるというより、コンピュータ用語も、言葉のもともとの意味、IT世界以外での使われ方で、理解するのが、本筋だと思っている。
Object (オブジェクト) は、もともとの意味は、「標的」とか「関心の対象」。
Subject(主体)が、特に関心を持っている対象が、Object(客体)になる。
関心事でないものは、世の中に存在していても、それは、Object とは呼ばない。
関心事であれば、実体がなく、頭の中だけに存在している概念でも、それは、Object である。
つまり、オブジェクトのモデリングとは、「関心事」のモデリングだということ。
業務アプリのオブジェクトモデリングとは、業務の関心事体系の模型を作ること。
業務の関心事が整理されている模型なら、表現形式がクラス図であっても、業務の専門家には、わかりやすいはず。
線の記法など細かいことは別にして、
パッケージ名
パッケージ内のクラス名
全体の並び
が、業務の専門家が自分の担当業務の主たる関心事に見えるようになれば、それが、良いオブジェクトモデルだということ。
(よくできた業務マニュアルの目次のイメージ)
当たり前だけど、「業務の関心事体系」であるオブジェクトモデルには、ソフトウェア開発には必要になる技術的な概念(用語)は、まったく含まれない。
中間的な関心事、最終的な関心事
業務の関心事といっても、中間的な関心事と、最終的な関心事がある。
ユースケースで考えてみると、
◎最終的な関心事:ユースケースの結果、手に入る情報とか、状態。
●中間的な関心事:ユースケースの途中で、作業に必要な参照データなど。
に分けることができる。
オブジェクト指向は、「目的」指向だから、「最終的な結果」が、もっとも重要な関心事になる。
中間の関心事も、業務アプリには、必要だけど、最終的な目的(オブジェクト)に比べれば添え物。
ユースケースに登場するすべての関心事をオブジェクトとしてフラットに列挙するのは、アンチパターン。失敗作ですね。
オブジェクト指向は、関心事、それも最終の結果、つまり目的を中心に物事を把握・整理する手法であり考え方なんだと思います。
ドメインオブジェクトのモデリングでは、いつも、「最終目的であるドメインオブジェクト」を中心に、ものごとを、理解し、整理することが大切。
業務の目的(重要な関心事)は、基本的には、
その関心事を記録する
その関心事を通知する
の二つです。
記録や通知の詳細な属性のモデリングの前に、記録したいことは何か?、通知したいことは何か?、その一番の関心事に、名前を付けること、それが、業務ドメインのオブジェクトモデリングの基本中の基本。
これは、ジャングルや暗闇の中で、迷走する作業ではありません。
ユースケースの名前に、最初からその答えがあるんだから。
注文を受け付ける
発注する
予約する
キャンセルする
「注文」「発注」「予約」「キャンセル」
これが、ドメインの主たる関心事。だから、これがそのままドメインオブジェクトになる。
後は、この主たる関心事オブジェクトが、どんな情報を持っているべきか、そこにどんな業務ルール/業務知識があるか、に注目しながら、モデル(模型)を、育てていけばよい。
簡単でしょう?
ポイントは「主たる関心事」、業務の「目的」オブジェクトを、まず、発見し、関係者で共有すること。
ここができてしまえば、業務ドメインのオブジェクトモデリングは、8割がた、成功したも同然です。
初期の段階で、業務の主たる関心事をとらえそこね、登場する言葉が、なんでもかんでも、オブジェクトに見えてきてしまったら、完全に失敗パターン。
業務の主たる関心事は、単純だし、明確なものです。
多くの技術者が、それをとらえそこねているのが、業務アプリ開発の実情かもしれません。
そんな難しいことでは、ないんだけどなあ。
「指向」から「志向」へ
私は、Oriented ( 指向 )という言葉は好きではない。
これは、無理やりにある方向に、整列させる、という、強制的な印象が強い言葉。
あるいは、教会の祭壇は「東向」が決まり、など、思考停止している印象がある言葉。
なぜそっちに向かっているのか、向かうべきか、直観的に伝わりにくい。
目的を指向すべきだ、というのは正しい。
でも、それは、言われたから、そっちを向いているだけ、という感じがする。
力づくで、そっち向きにさせられている。
私は、「指向」より「志向」のほうが良いと思っている。
「志向」とは、人間が、ある思いをもって、そちらに向かっている、という主体的、自発的なエネルギーを感じさせることばです。
目的「指向」は、営業目標のノルマを強要されているサラリーマンのイメージ。
目的「志向」は、自らの向かう道を見定めて、力強く歩いている、自律した起業家やプロフェッショナルのイメージ。
ソフトウェア開発でも、ドメインオブジェクト(業務の関心事)を「指向」しなさい、では、良いソフトウェアは生み出せないと思っている。
業務の目的に、自分も主体的に参加して、その目的の達成のために、みんなと協力しようという、「目的志向」の個人が集まること。
チームの各メンバーが、チームの「目的(最終結果)」を、共有して、自ら、そこに向かって力強く歩くこと。
それが、Object Oriented 「目的志向」なソフトウェア開発なんだと思う。