|
ここ最近 「オブジェクト指向のこころ」 を読み返しているのだが、読めば読むほど実に素晴らしい本だと思わずにいられない。当面この本を読んで気が付いたことを、メモ書き的に簡単に書いていこうと思う。
昔、まだプログラミングを習いたてのころは、「車」や「人」になぞらえてクラスやオブジェクトの説明をされたのを覚えている。現実世界の「モノ」をオブジェクトとし、それをそのままモデリングするという話だ。 ある特定の「モノ」とそれに関わる「属性」を取り上げ、「モノ」がオブジェクトであり「属性」がオブジェクトのプロパティやフィールド等のデータ、「モノ」が行う操作をメソッドとして捉え、クラスにするという話である。 例えば 「人」 であれば、名前や年齢をフィールドして扱い、歩いたり話したり等の動作をメソッドとして扱う等の話は、10年くらい前の本にはよく載っていたものだった。 しかし、当時はなんとなくそうなのかと思って鵜呑みにしていたものの、ここ数年「オブジェクト」とはそうではないことに気が付いてきた。 例えば数値・・・これは決してモノとは言えないが、言語によっては立派な「オブジェクト」である。 また Strategy パターンの Strategy クラス。これは「モノ」というより「戦略」という概念そのものをクラス化したものだ。また同様に Command パターンにおける Command クラス、これは「動作」や「処理」という概念をクラスしたものである。 こうなってくると
現実世界をそのまま写像できるという考え方は・・・シミュレーション用言語である Simula に触発されて生み出されたことと無関係ではありません。しかし、現実世界をそのままコンピュータ上に実装するなどできない相談なのです。
・・・中略・・・ 現実世界のものごとにはさまざまな性質、特徴が存在しています。そして、抽象化とはそういったものの一面だけを抜き出し、残りの面をすべて排除してしまう行為なのです。つまり現実世界のものごとに10個の側面があった場合、抽象化によって9個の側面が捨てられてしまうわけです。・・・ ・・・中略・・・ このため、「現実世界をそのままの形でクラスにできる」という宣伝文句も、最近では少しずつ目にする機会が減ってきています。 また、以前会社に来たあるコンサルタントはこういっていた。 オブジェクトとは決して難しい概念ではない。データにメソッドを持たせたものがオブジェクトである。
当時はこの言葉を鵜呑みにし、納得していたつもりだったが、今となってはそうは思えない。この書のなかでもこうバッサリ切り捨てている。 これはあまりにも単純で安直なものの考え方と言えるでしょう。なぜなら、オブジェクトというものを実装という観点からしか見ていないからです。
では「オブジェクト」とはいったいなんだろうか？「オブジェクト指向のこころ」の P104 で著者はこう言っている。
難しい言い回しだが、なかなか核心を突いた考えだと思う。この観点からオブジェクトというものを見ていけば、モノではない「処理」とか「動作」、「概念」すらも充分オブジェクトやクラスとして扱うことができる。 実際今の現場でもそうだが、消費税・料金・計算ロジック・支払方法・データ更新・請求etc・・・これらもモノとは言えないけど確かにオブジェクトとして扱っている。そう考えるとオブジェクトを「メソッドを持つデータ」とか「現実世界をそのままモデリングしたものがオブジェクトである」という従来の議論は誤りだといわざるを得ないだろう。 ありゃ？簡単に書くつもりが段々長くなってきたwww とりあえず今日はここまでにして寝よう。・・・と思っていたら寝付けないので編集しなおした。 ＃2/24 ちょっと修正した。
|
- >
- コンピュータとインターネット
- >
- コンピュータ
- >
- ソフトウェア
優れた書籍は読んでいて「すっきり」わかりますよね。
読まないとそれが分からないのが、難しいところです。
ある程度時間を投資しないと分からないので。
よい書籍の紹介、有り難うございました。
2010/2/23(火) 午前 7:23
はじめまして。
トラックバックしていただき光栄です。
オブジェクト指向で生産された汎化オブジェクト資産は再利用する事を前提にリファクタリングしながら且つ、新たに特化されたプログラムを作成するというスパイラルを繰り返していきます。
ですが、まだまだ殆どの現場がオブジェクト指向化されておりませんし、オブジェクト指向とは何か？という事も知らない人が殆どです。
少しでも分かっていれば使わない手は無いと絶対思うのですが、そんな事より面前の仕事に追われ次々と新しいサブルーチンを生み出しているというのが現状で寂しいかぎりです。
2010/2/23(火) 午後 0:24 [ かわじゅん ]
企業によっては導入が厳しいところがまだ多そうですね。私も色んな現場に入りましたが、コボル→ VB と経験してきたベテランさんには「オブジェクト指向」は難解でしかなく、「リファクタリング」はなおさら理解できないと言われたものです。
またこれは推測なんですが、現在企業の幹部となっている40〜50代の人たちも、若い時にはオブジェクト指向を取り入れ、「現実世界をモデル化したのがオブジェクト」「データにメソッドを持たせたモノがオブジェクト」等の話を鵜呑みにして開発したものの、生産性が上がる筈が返って作業が増大し「OOP は現場じゃ使えない」と誤った観念に縛られるようになった方が結構多いのかも知れません。
2010/2/23(火) 午後 2:10 [ hilapon ]
続きです。
むしろ今の若い世代・・・20〜30代の人たちが TDD とか活発に議論しながら開発したり、ブログやツィッタ―で意見交換しあったりしているのを見ると、今の世代は情報に恵まれているのだと思います。
若い世代が幹部クラスになる頃にはかなりの企業で OOP が導入される様になるのでしょうが、多くの企業で OOP が当たり前になるには、残念ながらもう少し時間がかかるのかも知れません。
2010/2/23(火) 午後 2:10 [ hilapon ]
ひらぽん様
どんなベテランさんでも、心の中では作り直したいっていう要求はあるんです。
でも工程管理という事に慣れているので、テスト済みのモノに更新する事のリスクを真っ先に考えちゃうんです。
そう言った考え方の根底には、仕事(要件)が一番大きな存在で、それに対してSEが見積りを規模(ステップ数)で計上し、そこに人月換算する事が当たり前なので、余計な工数(リファクタリング)は赤字となるため気持ちとは別に受け入れられないのです。
営業が取ってきた仕事をSEが見積り、設計して、PGがプログラムを生み出しテスターがテストしてOKになったら納品という大変分りやすい方式で作業するのが "作業標準" として君臨している限り、納品されたプログラムはアーカイブされるのみで再利用なんて考えられないのです。
今後も、ブログ・ツィッターがあるといっても、作業中にインターネットを活用する事が許されないプロレタリアートなプロジェクトではOOA-OOD-OOPを受け入れられる事無く、一部のオブジェクト指向に特化した企業(セクション)内でしか実践出来ないと思いますよ。
2010/2/23(火) 午後 9:05 [ かわじゅん ]
なるほど・・・業界の現状は厳しいようですね。
私も小規模案件から大規模案件の現場を一通り見てきましたが、OOP を理解できる人と仕事したのはごくわずかで、チームで OOP を理解しているプロジェクトは一つもありませんでした。
でも個人レベルで対処できる方法は色々とあるわけでして、どうせ言っても判らないと思い密かにリファクタリングしといたおかげで、納入寸前でいきなり仕様変更が発生したり、重大な仕様漏れが発見できたときに、わずかな期間で対処できたことが何度かありました。
2010/2/24(水) 午前 11:10 [ hilapon ]
ある案件では、業務の流れで 10画面ほど遷移するのですが、画面遷移のパフォーマンスがあまりに遅いので懸念していたところ、PM は
「納期に間に合わないし仕様に入ってないからこのままでいい」
と言い切っておりました。
＃ちなみに設計したのは私ではない。
しかし変更時のことを考え、単体のバグ取り中に重複処理を整理し、密かに DB 表示系の処理をクラスとして切り出しておいたのですが、予想はドンピシャで納入直前になって速度の遅さが大問題になり、重役達が顧客に謝罪に行く事態になったのでした。
2010/2/24(水) 午前 11:10 [ hilapon ]
結局1カ月の猶予を与えられ、画面ごとにDB からデータを取ってくる現状の仕様を、最初の画面でデータを全て取得し画面遷移の際は DataSet を使いまわすということに話は決まったのですが、
事前にリファクタリングしといたおかげで修正にかかった期間は一週間で済み、その間も徹夜なんかせず７時には、さっさと引き揚げていたのでした。
さらにおまけとして、この一週間の間に、他の人が書いた六千行の画面が、二千行にまで縮まっていたのでした。
最後、引き継ぎの際に、はじめて「リファクタリング」の話をさせて頂きましたが、残ったメンバがどこまで理解していたかは不明です。
2010/2/24(水) 午前 11:11 [ hilapon ]
私もCOBOLでOOP的な処理を組み込みました。(コーディング基準からは外れてましたけどね)
当時私の担当していたプログラムは他の方が音を上げたもので、50KStep以上で本数が120本ぐらいのボリュームでした。
COBOLって単純に変数定義を行なうと全てスタティック変数になんです。
まず処理性能がネックになっていたので、automatic sectionで出来るだけ変数を定義し直し、また一度DBから読込んだ基本レコードをスタティック変数に置くサブルーチンを作成し、同一ソース上に２次入り口を作成し、スタティック変数上のデータからのチェーンデータを詠込む様にしました。
周りの人々は２次入り口がある自体知りませんので引継ぎ後で、「サブルーチンをCALLしてるんだけど該当するソースが無いです」と問い合わされ「そのサブルーチンならｘｘのソースの２次入り口として定義しているよ」って答えておきました。
でもおかげで、チェーンデータを取り出す度に基本レコードを読込み直していた回数を激減させました。
結局開発技法とか、言語の理解があればどんな言語でも実はOOPL出来てしまうって事で。
2010/2/24(水) 午後 1:48 [ かわじゅん ]
> 優れた書籍は読んでいて「すっきり」わかりますよね。
逆にとんでもない本もあるみたいですね。
これはひど過ぎる！！＞＜
http://d.hatena.ne.jp/bleis-tift/20090301/1235850947
http://d.hatena.ne.jp/bleis-tift/20100224/1266983847
2010/2/24(水) 午後 5:31 [ hilapon ]