« ポリモーフィズムの仕組み | Main | 人月見積もり問題を会計的な視点から »

March 24, 2008

オブジェクト指向プログラミングは万能選手ではない

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第202号 2008/3/24 『OOPは万能選手ではない』
▼ まえがき:「ソフト会社の心臓ブログ」開設
▼ [オブジェクト指向再入門] (1)抽象メソッド、抽象クラス
▼ [オブジェクト指向再入門] (2)フレームワーク
▼ [オブジェクト指向再入門] (3)OOPは万能選手ではない
▼ 次回以降の予告

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
まえがき:「ソフト会社の心臓ブログ」開設
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

蒲生嘉達(がもうよしさと)です。

2月12日に「ソフト会社の心臓」を出版しました。
Amazonで「なか見!検索」もできます。
http://amazon.co.jp/exec/obidos/ASIN/4779002958/keiitteanifty-22

また、「ソフト会社の心臓ブログ」を開設しました。
URL: http://www.gamou.jp/heart/

今後はそこから質問への回答、誤植訂正、セミナー情報を発信していきます。
既に、質問への回答1件、誤植訂正6件など、12件の記事を掲載しています。

また、「ソフト会社の心臓」について、ご質問があれば、info@kei-it.com
までお寄せください。

今回も引き続き、オブジェクト指向プログラミングについて解説します。
「オブジェクト指向プログラミング」は本文では「OOP」と略します。
英語の'Object Oriented Programming'の略です。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[オブジェクト指向再入門] (1)抽象メソッド、抽象クラス
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第197号から第201号まで、OOPの三大要素であるクラス、継承、
ポリモーフィズムをコンピュータの中の動きから解説しました。

さて、第201号での占いクラスの鑑定メソッドは、実際にはロジックは
存在する必要がないことに気づいた読者もいるでしょう。

 第201号:ポリモーフィズムの仕組み
 [B] http://kei-it.tea-nifty.com/sailing/2008/03/post_a142.html
 [H] http://www.kei-it.com/sailing/201-080310.html
 

ロジックが存在しないメソッドは「抽象メソッド」と呼ばれます。
「抽象メソッド」が存在するクラスは「抽象クラス」と呼ばれます。

そして、

抽象クラスはインスタンス化できません。
必ず継承されて、継承したサブクラスがインスタンス化されます。
このとき、抽象クラスの抽象メソッドはオーバーライドされて、
完全なものになっていることが必要です。

     ( http://www.nextindex.net/java/abstract.html )

第201号での「図201-2:四柱推命の動き 」でも、「占星術インスタンス」
や「四柱推命インスタンス」はありますが、「占いインスタンス」は
ありません。

 図201-2:四柱推命の動き
 http://www.kei-it.com/sailing/2008/201-2.htm

「抽象クラスはインスタンス化できません」という規則は、言語仕様
で決められているから存在するというよりも、継承やポリモーフィズム
の仕組みから必然的に出てくる性質なのです。

第200号、第201号のように、一度内部で起きていることを順を追って
見てみると、その後の理解の速度と深度が違ってきます。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[オブジェクト指向再入門] (2)フレームワーク
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

OOPの三大要素によって、プログラムの再利用について新しい方式が
可能となりました。

その一例がフレームワークです。

フレームワークはよく次のように説明されます。

フレームワークとは不完全なアプリケーションのことであり、開発者は
それを完成させることで、一つのアプリケーションを開発することに
なります。
( http://www.nextindex.net/java/Struts/index.html )

「不完全なアプリケーション」が先に存在し、そこから呼び出される
側を後から作るという開発手法は、ポリモーフィズム(呼び出す側を
変えなくてもよい)を活かしたものです。

このような開発手法は構造化プログラミング言語からは生まれてきません。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[オブジェクト指向再入門] (3)OOPは万能選手ではない
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

しかし、コンピュータの内部からOOPを見ると、OOPが万能選手でない
ことも分かってきます。

OOPは、クラス、継承、ポリモーフィズムの仕組みの上で動きますが、
それらの仕組みを必要としない、あるいは、むしろ有害となる分野も
あり得るのです。

あるいは、システムの一部でのみOOPが有効に機能する場合もあり得ます。
システムの全てをOOPで作る必要もないのです。

様々な例が考えられますが、ここでは数例のみ上げましょう。

OOPは「ヒープ領域をじゃぶじゃぶ使って動く」(平澤章氏)ので、
ヒープ領域が潤沢にあることが前提となります。
極めて限られたメモリ資源で動くプログラム、例えば、組み込み系
プログラムでは、今後ともCが主流であり続けるでしょう。

また、アプリケーションプログラムであってもOSのネイティブの
機能へと降りていく必要のある部分では、やはりCが主流であり続ける
でしょう。

「OOP+RDBMSのストアドプロシージャ」というパターンも広く使われ
続けるでしょう。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
次回以降の予告
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

次回発行予定は、4月上旬です。

今週号で「オブジェクト指向再入門シリーズ」は一段落したので、
次回は別のシリーズを予定しています。

乞うご期待!!

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
本メルマガについて
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

私は中小ソフトウェア会社の経営者なので、(特に日本の)ソフト
ウェア業界、ソフトウェア産業について強烈な興味を持っています。
技術面だけでなく、会計面、法律面、人事面など様々な面において・・・。

そして、私はものごとを見るときに次のことを心がけています。

・あるものをあるがままに見る。
 色眼鏡(例えば権威者の意見)でものを見ない。

・くっきりはっきり見る。
 複雑な現実も、ある観点から見ると、あるいはある角度から光を
 あてると、くっきりはっきり見えてくる。

・批判だけではなく、明るく前向きな解決策を提示する。

この視点で見えてきたことを本メルマガに綴っています。

本メルマガの内容に興味を持つであろう方をご存知なら、是非、
本メルマガの存在を教えてあげてください。

(以下をそのまま転送するだけです。)
---------------------------------------------------
【お勧めメルマガ ソフトウェア業界 新航海術】
⇒ http://www.mag2.com/m/0000136030.htm または
 http://kei-it.tea-nifty.com/sailing/ または
 http://www.kei-it.com/sailing/ 
--------------------------------------------------

このメールマガジンは『まぐまぐ!』 http://www.mag2.com/ を利用して
発行しています。配信中止はこちら http://www.mag2.com/m/0000136030.htm
(但し、慶社員には社内のメーリングリストで配信しています。)

「まぐまぐ!」での読者数は2007年3月23日現在、670名です。

バックナンバーは、発行者サイトまたはブログで、体系として
見てもらいたいので、「まぐまぐ!」でのバックナンバー公開は
最新号のみとなっています。

バックナンバーブログ:http://www.gamou.jp/sailing/
発行者Webサイト: http://www.kei-it.com/sailing/
(発行者Webサイトではバックナンバーの全文検索も可能です。)

|
|

« ポリモーフィズムの仕組み | Main | 人月見積もり問題を会計的な視点から »

Comments

Post a comment



(Not displayed with comment.)




TrackBack

TrackBack URL for this entry:
http://app.cocolog-nifty.com/t/trackback/62022/40621924

Listed below are links to weblogs that reference オブジェクト指向プログラミングは万能選手ではない:

» 構造化設計 [構造化設計]
プログラムをモジュールに分割するときには、システムの頻雑さを最小限に抑えるために、モジュールの関係が階層構造になるように設計するという方針で作業を進めます。 [Read More]

Tracked on March 27, 2008 at 12:58 AM

» ネイティブの機能へと降りていく必要のある部分 [新航海術の補足]
第202号(2008/3/24)『オブジェクト指向プログラミングは万能選手ではな [Read More]

Tracked on July 13, 2008 at 11:07 AM

« ポリモーフィズムの仕組み | Main | 人月見積もり問題を会計的な視点から »