オブジェクト指向 のメリット まとめ

ユーザー・クライアントは、何らかの問題・課題を解決したいが故に、システムを構築する。
オブジェクト指向は、その問題領域の要望・要求の構造と振る舞いを、オブジェクト群とそれらの連携（協調）で、モデル化することができる。
システムのデザイン・設計とそのアーキテクチャも、オブジェクトとそれらの連携
コンストラクションの単位もオブジェクト
再利用・部品化・共通化の単位もオブジェクト。
ユーザの業務から実装まで、オブジェクトという考え方で、トレース可能なものにできる。

ユーザ・クライアントの基本的な考え（コンセプト・ビジネスモデル・ワークフロー）を、抽象化して計算機に入れてしまう。ユーザ・クライアントの心、気持ちを、忠実にシステムに反映させる。

オブジェクトは、極めてカプセル化され自立している。そのオブジェクトに機能が不足している場合、継承で新しいオブジェクトを作る、隣に別のオブジェクトを作りメッセージで繋ぐなどができる。

カプセル化により、中をどうしようと、システム全体としては、問題にならない。オブジェクトの外側のI/Fはそのままにしておき、アルゴリズムを変える、チューンする。I/Fが一緒の別のオブジェクトと入れ替える。

業務から実装までトレース可能なオブジェクト指向だか、その記述に使われるのがUML。

クラス図だけとは言わず、入り口から使用しないと、ありがたみが減ずる。

言語の歴史 4 オブジェクト指向

構造化言語も頑張った。が、やはり時代が許さない。

今まで、コンピューターは、本質的に「計算機」として使われてきた。ＸＸシステムとかＸＸアプリ。外装の機能は変わっても、やってることは計算機。

が今は、ネットの携帯、メール等、独立した個々の間ののメッセージツール、コミュニケーションツールになってきた。計算、演算の処理であれば、構造化言語でも十分対応できた。しかし、巨大なネット空間、トポロジー、メッセージ伝送を、モデルとしてとらえようとすると、手続き型や構造化の考え方では、表現が非常に困難。できないといってもいい。
web2.0のシステム概念など、オブジェクト指向そのものだ。

世の中でおきていること、シカケ、ビジネスの仕組み。問題領域、システム化対象領域の多くは、オブジェクト指向で表現するほうが、無理が無い。できないと言ってもいいかもしれない。
オブジェクト指向は、エンジニア、プログラマのニーズや好みで生まれたものじゃない。

C++より後発の、Java PHP5 Ruby などは、ネットを意識して、マシンをまたいでのメッセージ連携、プロセス間通信が、最初からできる。ネットに関係するコンストラクションの際に、今はそれらを選択することが妥当だろう。勿論、次に何が来るかはわからない。

今、ＰＧとしてするべきは、オブジェクト指向を理解したうえで、それらの処理系を使いたい。
JAVAのクラスメソッドをたくさん覚えても、オブジュクト指向を理解したことにはならないんで。

C++ JAVA PHP5 Ruby,Squeak
本稿では、いつもの言語の説明はしない。馴染みは十分あるだろうし。

言語の歴史 3 モジュール指向

言語の中*で* プログラムすることと、言語の中*へ*プログラムすることは、大きく異なる。(Gries 1981)
別に稿を書き起こす予定だが、ひとつの言語しか知らないと、その言語の仕様に限定された発想、思考しかできない。いくつかの言語を知っていれば、問題を解決するための最適な処理系の選択ができる。これは堅牢なアーキテクチャの確立のひとつの要素だ。

と、ぶち上げて、モジュール指向の言語の話だが、これ日本で全然、流行らなかった。好きな人の間で、「いいよねえ」「よさげだよねえ」と言ってたんだが、ビジネスベースでは、ほとんど使われてない。それだけ、cのインパクトでかかった。

モジュール=名前空間　として、抽象化されたデータ型を作る。

Ada やっぱりアメリカ国防省がからむ。データ抽象化と情報の隠蔽、パブリック、プライベートの考えなどをもつ。ちなみに、Adaさんという人は数学者で、世界で最初のプログラマと言われる。コンストラクションが難しい時、祈るといいことがあるかもしれない。

Mudula2 ごめんなさい、ほとんど知りません。ライフボード社で扱っていて、処理系売ってたんだけど・・・お小遣いじゃ買えませんでした。

言語の歴史 2 手続き型 構造化

オブジェクト思考の背景として歴史を知ることの他にも、コンストラクションの重要な決断をするためには、言語の種類、特色は理解しておくべき。どうしてこのシステム構築にあたって、PHP5を選択しているのだろう。いつまで、半人前のＰＧでいいなら知らなくても、考えなくてもいいけど。

COBOL アメリカ国防省向けに作られた。今でも大量に資産がある。
手続き型から進歩も続けていて、構造化COBOLや、最近では、オブジェクト指向の機能を持つCOBOLまである。不勉強で、オブジェクト指向COBOLの詳細は知らない。

Fortan 手続き型でスタートだが、Fortran77では、ブロック構造のIfが追加され、構造化への歩みもしている。

C 低水準に移植性の高いアセンブラとしても使えるし、構造化された制御、マシンからの独立（一応は）など、高級言語としての機能も。1980-1990年代、オープン系開発では、事実上の標準ともいえる。

手続き・構造化は、ずいぶん、がんばってイロイロなことを試みる人たちがいた。
同じようなところを、まとめて、サブルーチンとして使いましょうよ。
アセンブラまでは職人だけだったが、この頃から、プログラムが大衆化して、それこそ、ぐちゃぐちゃになって、コードの書き方何とかしましょうや。で構造化。

ちゃんとやれば、それなりに理解しやすいプログラムになる。でも、再利用できるのはあくまでも、コードのレベル。それ以前の、分析・設計の再利用性は、ない。勿論、コードと業務のつながりは直接的にはなく、ドキュメントのみが頼りになる・・が、このドキュメントが十分であることは・・マレだ。

言語の歴史 1 機械に優しい

オブジェクト指向の必然性を理解する上で、言語や処理系の歴史を、背景として知っておくことは有効だ。

まず、機械語やアセンブラの時代。
当時は、マシンもメモリも高かった。人が、機械様にスリスリしていく必要があった。人間はコンピュータの気持ちになって、0と1の羅列をする。（16進でもいいけど）
アセンブラのニーモニック。ちょっとだけ人にとって意味を持った。でも ADD はマシン語の010011だよね、とマッピング、紐付けしただけ。

長所は、マシンと環境と地球に優しい。エコだったんだな。早いし。
少しでも便利にしようと、歩み寄りもあって、マクロアセンブラとかも出たな。でも本質的には、普通の人には焼け石に水。もう職人芸の世界。
どうしても実行速度を負う、コードサイズを小さくする必要性があれば、今でも使われる。

そして欠点は、勿論、ふつ～の人は見てもわかんねえ。

化け物はいるもんで、16進をみてニーモニックに直せる人間逆アセンブラーとかいたなあ。尊敬されてた。でも俺はできません。

ソフトウエアクライシス対応 5 I/F重視

システムデザイン、アーキテクチャを確立する時、I/Fを重視した設計を進める。コンポーネントに分けることで、並行開発ができる。場合によってはアウトソーシングもできる。
疎結合であれば、依存度も低く、問題の切り分けがしやすい。

この発想がないと、web2.0的な外部システムのサービスを取り入れたシステムデザインは難しい。一応つながってはいるけどね、キレイじゃないよね。って、システムデザインになる。あとで誰かが苦労する。

オブジェクト指向は、現在のソフトウエアクライシスに対応する中心的な要素になり得る。が、オブジェクト指向でやれば、すべてうまくいくというような、魔法の薬ではない。
この問題を考えていくと、ソフト会社って何？ソフトウエア開発って何？　さらには、ソフトウエアエンジニアリングそのものの議論になっていく。
そのあたりは、きっとアジャイルのメンバーのお歴々が、やっていかれると思うので、お任せしておきたい。

オブジェクト指向の背景として、現代のソフトウエアクライシスに、文字を費やしたが、次は、オブジェクト指向の背景の２つ目として、言語、処理系の歴史を押さえておく。

ソフトウエアクライシス対応 4 フレームワーク

JavaでもPHP5 でも、いいフレームワークが揃ってきている。c++の時代とはずいぶん違う。
使用実績のあるフレームワークを会社に作っておく。蓄積していく。繰り替えし利用することで、毎回テストされ信頼性があがる。
昔でいえば、サブルーチン、プロシージャ、関数の共通化だったが、いわば局所的なパーツの蓄積。その意味では、ずいぶん進歩はしている。

オブジェクト指向の再利用性は、コードにとどまらず、分析、設計にまで及ぶ。経験も必要だが。

新技術は毎日のように出ていて、クライアントは新しいものが魅力的に見える。だか最新ということは、実運用を踏まえた安定性に欠けるということ。バグがあるに違いない。
だが、取り入れなければ、ジリ貧だ。そのリスクを回避しながら、開発することになるが、やはりインクリメンタル開発となる。とにかく、細くてもいいから、ガイドロープを向こう岸にかける。一番最初に、アーキテクチャーのプロト、サンプルコードを書く。
妥当性の検証はしっかりと。
これで、新しいものを取り入れたフレームワークが作れる。

ソフトウエアクライシス対応 3 アーキテクチャー

サービスインまでの仕様変更。そして勿論、サービスインして運用がはじまってからの機能追加。当然、あるべきものと考えておく。
システムは生きていれば成長する。成長の止まっているシステムは、使われない死んだシステムだ。言い過ぎかもしれないが、１００歩譲っても、世の中やビジネスが変わるのだから、それにあわせていかないシステムやサービスは、いずれ死ぬ。

おたおたするな、ガタガタするな。仕様変更や追加はある。そう割り切っておこう。費用などの点は営業的な話なので、今回は省略するが、問題は、それに耐えられるベースのアーキテクチャか否かだ。

オタオタしないための仕込み。それが安定したアーキテクチャだ。レガシーでいえば「方式設計」だが、オブジュクト思考でやるときには、インフラやベースラインのアーキテクチャ。機能を実現するレイヤ、ビジュアル（プレゼン）を担当するレイヤ。それぞれ独立してメンテできるようにしておく。MVCのフレームワークはいくつもある。その採用もいいだろう。

アーキテクチャがしっかりしていても、オタオタしないためには、条件がある。開発者が信頼に足り、物事の決定の場に立ち会えること。コミュニケーションが十分にとれていること。などなど、オブジェクト指向以外の要素があるが、XP(Extreme programming)について書くときにあらためて。

アーキテクチャの確立については、別途書き起こすが、ここでハッキリ書いておきたいのは、サービスイン前にクライアントからアーキテクチャの変更まで求められるような要望が出た場合、PM,PLは断固とした姿勢で挑むべき。なぜなら、それはプロジェクトのゴールが変更されたと同等のことで、このまま進めても、クライアントは満足するわけがない。もっとハッキリ言えば、必ず失敗する。ならば、プロジェクトの中止、仕切りなおしをするのが、誠意だと考えたい。

アジャイル宣言
契約交渉よりも、ユーザとの協調により価値をおく
計画に従うよりも変化に対応することにより価値をおく

ソフトウエアクライシス対応 2 見積もり

これをちゃんとやらないと、ソフト会社なんてすぐに潰れる。当たり前のことだが。いろいろな方法もあるから、一例を挙げるに留める。

機能の細分化。コードとUTは人日単位まで落とし込む。コード UT以外のやるべきタスクの洗い出し。それを積み上げる。
スケジューリングは、細分化された機能等を、タスクまたはwbs としてカレンダーにマッピング。優先順位もつける。

機能の細分化の際、オブジェクト指向でやる。すなわちオブジェクトや、それに含まれるメソッドが、ビジネスの要素にマッピングされるので、クライアントにも理解されやすい項目となり得る。同時にその見積もりの項目は、必要なクラス一覧にマッピングされる。

要求は変化する。要望は追加される。その要望を実現するために、どうして追加のリソースや工数が必要になるのか、クラス・メソッド一覧にマッピングできる見積もりは、クライアントへ、十分な説明が可能になる。

もっとも、開発論、技術論ではないところで、大枠の金額や納期は圧縮されるんだけど、オブジェクト指向とは関係ないので省略・・。

ソフトウエアクライシス対応 1 クライアントと握る

クライアントの考えていることをシステムデザインにキチンと反映する。当たり前のことなんだが、現実はキチンと決まらない。クライアントとの定例会議の最初の頃は、クライアント自身が考えが至らなかった事柄もある。要望は段階的に出てくる。

ダイナミック、インクリメンタルな開発は世の流れとして必要となる。そのためには、UMLなどを用いて、対クライアント、対内部のコミュニケーションコストを下げておく。オブジェクト指向はビジネスをモデル化することがキモであるから、うまく機能していれば、従来の設計レビューより、クライアントと握りやすい。

リリースは段階的に行う。一気に作るのは、このご時世では危険。小刻みにプロトを出す。外部仕様だけでも早い時期に見せていく。html紙芝居も有効な技。

クライアントの考えていることとは、「要求仕様」とは異なる。ここは大きなポイントだ。
今まで、システム開発の目的は、「要求通りの構築」だった。しかし時代のニーズは、システム開発の目的を「満足とビジネスの成功」にしてしまっている。
要求とは「確定させるよう吸い上げるもの」から「変化するもの、随時対応するもの」になっている。

ゴールとその効果測定（定量）まで、初期にヒアリングし、握っておく必要がある。

ソフトウエアクライシス3 ネット WEB2.0

ネットを前提としたシステムは、不特定多数の利用者を持つ。ネットを前提としていなければ、有る意味閉じたシステムともいえる。有る程度、ユーザが決まっていた。しかし、ネットにUIを持つ・開放するということは、データ更新を伴うオペレーション・操作を不特定多数の人間が行うことを意味している。ネットの前の時代なら、そんなこと怖くてやらなかった。

ネットやWeb2.0になって、ハードやソフトやAPまでも、IPリーチャブルなどこかに置かれている。そういうシステム連携をキチンとデザインできなきゃいけない。少なくとも、それを理解しイメージできてないと、コードもちゃんと書けない。

さあ、ラッピングだ。APIだけ覚えりゃいいにしちゃいましょう。
例えば、オープン系からキャリアスタートの俺が何だかんだ言おうと、ホスト、基幹、汎用には、既存のソフトウエア資産が大量に積まれているのは事実だ。その資産を利用することも必要とされる。だから外側に皮を被せる。ゲートウエイと言ってもいいかもしれない。外からみれば、オブジェクト志向で作られたAPIだけだ。中（裏）では昔のままのレガシーアプリが動いている。中は皮とメッセージ連携、イベントドリブで連動させる。

amazon でも、googleMaps でも、中で、何が動いているかなんて、どーでもよい。
APIで何が提供されているかだけが問題になる。

ブラックボックス化、API化によって、ネットが社会のインフラとして重要度はさらに増してきている。ちょっと前まで、ブラウジング、情報得る、見るだけのお手軽システムだった。せいぜい、ちょいとCGI。

ecサイト。B2B B2C。取引、決済が、ネットをインフラとして電子化されている。それは閉じた世界じゃない。ネットというオープンな世界のテクノロジを使う。xmlを使って、取引の区別をなくそうともしている。（標準化委員会の結論はどうなったかな）
従来のクローズされた世界のシステム以上に、堅牢であり、信頼できることを要求されている。そいつを２ヶ月でやれと求められる。泣いても許してもらえない。

さあ、どうしましょう。

だからこそ、十分テストされた信頼性の高いコンポーネントを使う。それは自分のシステム外でもいい。信頼できれば。
I/F重視、徹底したコンポーネント・モジュール化。

そのシステムデザインをステークホルダが共有する。共有するというのは、単にファイルを共有するということではなく、仕様や設計レベルも含めて共有する。それがないと、前節のインクリメンタル開発は実施が困難になる。そのシカケ、方法のひとつとしてUMLがある。それをチーム開発のリファレンスとする。しかし、UMLで表現すれば、問題が解決するわけじゃない。モデリングが大事であることは論を待たない。モデリングのコアは、アーキテクチャ確立で、これがブレることはプロジェクトのゴールが変わったことを意味する。

ソフトウエアクライシス2 さっさとやらんと他社に負ける

計算機は神様で、電算室、EDP室という神殿があり、技術者は神官であり神主だった。帳票１種類追加してよとお願いすると、完成は１年後ですというご託宣が下ったりした。企画し要求をまとめ仕様を決め、設計、製造、テストまで、２年とか３年でよかった。今でも、インターネットバンキングだと、ページの文言を変更するのに１ヶ月は必要だ。

大半のネットの世界には、そんな幸せはない。
ECサイトを作りたい、というクライアントがいる。
３年前だとカットオーバに３ヶ月もらえた。今じゃあ２ヶ月だ。

さあ、その２ヶ月で、クライアントのビジネスモデルを理解し、時には一緒にモデルを作りつつ、デザインして、コード書いてテストして。
その間に、そのクライアントのライバル・競合会社が、新しい機能をつけたりすると、すぐにつけろ、となる。
携帯のコンテンツをサーブするシステムだと、企画責任者が「ピンクのハートと黄色いハートじゃあ、集客力が違うのよ！」と、直前に言われたりする。PGの「どっちでもいいじゃん」みたいな話は通用しない。それはユーザの嗜好性に基づいたプロジェクトの成否をわける話だから。
画像の差し替えじゃなく、機種依存の絵文字の話だから、かなりややこしい。

開発サイドは、かなり苦しく負荷が高くなる。近々そうなるという話じゃない。もう、そうなっている。

さて、じゃあ、どうするか、だ。

ひとつは、０から作るのはやめましょう、と。
業務・業種で、こういうワークフロがありますね、と。それに対応するフレームワークを作りましょう。コンポーネントの組み合わせを想定しておいて、クライアントの要望をコンポーネントにしてプラグインしていく。
昔からあるパッケージソフトとか、ライブラリー群との違いわかるかな？
コンポーネントとしてプラグインするってところが、オブジェクト指向風。
そして、コードの再利用だけじゃなく、分析・設計の再利用も。
いい悪いというより、そういうスタイルにしなきゃしょうがない。

もうひとつは、仕様変更・追加は必ずあるとリスク管理しちゃう。
リスクといっても、昔のレガシーのころからの工数を大目にするって話ではない。
クライアントとシステムアナリストが、仕様まで落とし込み、コード化がはじまった。しかし、最終は、マーケット、ビジネスを、クライアントとアナリストが読みきったかどうかが大事で、読みが甘いとそこで仕様は変更される。
費用は別として、仮に対応しきれないと、クライアントは満足しないし、クライアントのビジネスは成功しないし、次の仕事はこないし、会社は生き残れない。
最初にいったけど、技術サイドの話じゃない。世の中にニーズの話だ。
アプリの仕様の変更、追加は、クライアントのビジネスの成功のためには、当然のことだ。それが世の中のニーズで、ソフトウエア開発者にとっては、生きていくのがイヤになる時代になった。
だから、インクリメンタル開発。プロトを提示し、早期に確認し、繰り替えし、積み上げの開発が、世の現実のニーズに近い動き方といえる。

以上、webのビジネスサイトを中心に書いたが、組み込みの世界でも、期間圧縮のプレッシャーはかなり強いとのこと。
携帯電話のバグで回収騒ぎがあるが、中身の８０％以上がソフトウエアで、２,３ヶ月のスケジュールで、テストも全てこなせず、品質としては問題があるのはわかっていても、生き残るためには、ヤムナシと市場に投下せざる得ない・・ということも、聞いたことがある。

ソフトウエアクライシス1 組合わせは星の数

ハードウエアや、O/S ミドル。必要とされるソフト数、テクノロジー、要素は増える一方だ。それらを適切に組み合わせることが必要とされている。
さらに、ネットも加わる。ネットを前提として、ＰＣを前提とし、さまざまなデバイスを前提としている。

従来のEDP室に鎮座増します計算機様では、クライアントにとっての意味がなくなってきた。連動して動いていくことに価値や意味が生み出される。組み合わせ、連動の世の動きは、WEB2.0にまで行き着いている。

組み合わせは星の数。とってもやってられない。
で、抽象化、仮想化、I/F重視という考えが出てくる。
オブジェクト指向を使って、まず組み合わせの要素を抽象化しインテリジェントなオブジェクト・仮想化されたデバイスにしちゃいましょう。
そしてその間、I/Fで、どういうプロトコルで、どういうメッセージをやりとりさせますか、という視点から、デザイン、設計を進めていきましょう、と。

これで、設計・デザイン上では、さまざまな機器の違いを吸収して、話そうとする。

そういったことを実現するひとつの方法として、Javaがある。
JVM(Java Virtual Machine)では、APIさえ知っていればいいんだよ、と。SUNが一生懸命その流れを作ろうとしていた。（APIを利用するだけのPGが、本当にPGと言えるかどうかの議論は別の機会-ソフトウエア職人気質-でやる。）

Javaを否定するつもりはない。が、大事なのは、Javaそのものではなく、仮想化、抽象化、I/F重視というデザイン姿勢を身に着けること。そして、自分の設計に適用していくこと。
ここを理解できてしまえば、Javaの流行が終わっても、次の処理系に移っていくことができる。

そして、そういう思想でデザインされたシステムこそ、クライアントの資産となりうるのであって、抽象化も、仮想化も十分にされてないけどJavaで書きましたといっても、それの価値には疑問をつけたい。

背景:ソフトウエアクライシス

オブジェクト思考が持てはやされた背景には、ソフトウエアクライシスがある。
最初から技術・開発サイドからどうこうというより、社会的要請、クライアント自身はその要望が進化・高度化してきたことを、開発サイドが、追いかけて出てきた概念だと思う。
はじめに、技術有りではなく、ニーズ有りだった。

その必要性を理解する中心に、ソフトウエアクライシスがある。
ソフトウエアクライシスという類の話は、３０年前からある。が、当時の危機は、ソフトウエアエンジニアが不足していくことが心配されていた。
今は、まあ、数はいる。それこそ、Perl しか書けないPGでも、一応は生きていける。
ちなみに昔は、COBOLができれば一生食えるよねと言ってたけど、食えはするけど、それだけじゃ、上には行けない。変化についていく、世のニーズにあわせて、自分を変革させないと。

今のソフトウエアクライシスとは、ソフトウエアのPGの不足ではなく、いわゆるウオーターフォールで言う上流、クライアントのニーズをモデリング、デザインすることができる人が不足している。ここでいうデザインとは、ヴィジュアルではなく、システムデザインだ。

今できるか否かの自己認識は大事だが、それ自体は問題じゃない。生き残るためには、現在の世のニーズをつかみ、自らをも進化させることが、必須となる。

オブジェクト指向概論 目的

オブジェクト指向(オブジェクトオリエンテッド)について、基本的な考え方と周辺のモロモロをまとめていこうと思う。これによって、オブジェクト指向の有効性を、ニーズとシーズの両面から説明を、数十回？にわたって試みてみたい。

ブロジェクトのおいて自分がオブジェクト指向を理解しているだけでは、実は足りなくて、社内、組織、チームで、オブジェクト指向開発が有効に機能しないことになる。人に説明できることが重要になる。

試みるポイントは、
ウオータフォールとの比較と経緯。
ＵＭＬの基本文法とモデリングに触れる。

オブジェクト指向開発を、乱暴に、即物的言ってしまえば、UMLで設計をすすめてていく開発プロセスだが、知識があれば成功するわけではない。
若干ではあるがリスク管理にも触れる。