**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第198号 2008/1/21
『インスタンスはヒープ領域に作られる』
▼ まえがき
▼ [オブジェクト指向再入門]　(1)良書である理由
▼ [オブジェクト指向再入門]　(2)インスタンスはヒープ領域に作られる
▼ [オブジェクト指向再入門]　(3)Cでのヒープ領域の使用方法
▼ [オブジェクト指向再入門]　(4)Javaでも同じようなことをやっている
▼ [オブジェクト指向再入門]　(5)Cは手動メモリ管理
▼ [オブジェクト指向再入門]　(6)メモリ自動管理の唯一の弊害
▼ 次回以降の予告


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
まえがき
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

蒲生嘉達（がもうよしさと）です。

いよいよ拙著「ソフト会社の心臓」が2月12日(火)に出版されます。
出版社からカバー案（↓）が送られてきました。
http://www.kei-it.com/sailing/img/soft.jpg


さて、今日は、引き続き「オブジェクト指向プログラミング」に
ついて話します。

「オブジェクト指向プログラミング」は本文では「OOP」と略します。
英語の'Object Oriented Programming'の略です。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[オブジェクト指向再入門]　(1)良書である理由
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第197号でもふれた「オブジェクト指向でなぜつくるのか」(平澤章著、
日経BP社発行）を読み終わりました。

　(第197号：インスタンスという仕組みが画期的である理由
　http://kei-it.tea-nifty.com/sailing/2008/01/post_606d.html )


私は、次の二つの点で、この本は良書だと思います。

（１）
プログラミング技術であるOOPと、上流工程で使われるオブジェクト
指向技術(モデリングなど)とを明確に区別して書いています。

（２）
OOPの特徴はメモリの使い方にあると指摘し、そのメモリの使い方
の側から、クラス、インスタンス、ポリフォーフィズム、継承
などの仕組みを説明しています。

OOPをメモリの使い方の側から説明している本は珍しいと思います。

（１）については別の機会に話すとして、本日は（２）について
話します。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[オブジェクト指向再入門]　(2)インスタンスはヒープ領域に作られる
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

例えば、インスタンスの生成について、同書では、

> インスタンスを作る命令が実行されると、そのクラスのインスタンス
> 変数を格納するのに必要な大きさのメモリがヒープ領域に割り当てら
> れます

と説明されています。


例えば、Javaで次のように書くと、Bookインスタンスがヒープ領域に
作られます。

　Book WhyOOP = new Book(); // Bookインスタンスの作成


ここで「ヒープ領域に作られる」というところが重要です。


------------------------【基礎知識】------------------------

プログラムが動くときに使われるメモリ領域には、静的領域、
スタック領域、そしてヒープ領域の３つがあります。

静的領域とはプログラムコードやグローバル変数が格納される領域です。
スタック領域とはローカル変数、引数、呼び出し元アドレスが格納
される領域です。

それに対し、ヒープ領域とはアプリケーションが自由に使えるワーク
領域のようなもので、アプリケーションが必要とする大きさの領域を
必要とする期間保持できます。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[オブジェクト指向再入門]　(3)Cでのヒープ領域の使用方法
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第197号では次のように書きました。

> Cで複雑な構造を持つデータを共用する方法は次の二つです。
>
> ・グローバル変数
> ・呼び出し元で構造体などを作り、呼ぶときにはその領域のポインタ
> 　を渡す。

　( 第197号：インスタンスという仕組みが画期的である理由
　http://kei-it.tea-nifty.com/sailing/2008/01/post_606d.html )


Cでは、ある関数内でヒープ領域を獲得し、そこに構造体などを作り、
その領域のポインタを使って様々な関数がその領域にアクセスすると
いうことをよくやります。

スタック領域に作られる変数（ローカル変数）はその関数が呼び出
されているときにしか存在しないため、一定期間データを保持したい
ときには使えないからです。

また、グローバル変数として静的領域に作ると、プログラムサイズが
大きくなるし、保守性が低下するからです。


Cでは上記処理を具体的には次のように書きます。

・malloc関数でヒープ領域を獲得する。
・その領域のポインタを引数として、他の関数を呼び出す。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[オブジェクト指向再入門]　(4)Javaでも同じようなことをやっている
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

実はJavaでも同じようなことをやっているのです。

　Book WhyOOP = new Book(); // Bookインスタンスの作成

というコードは次のことを意味しています。

・ヒープ領域を獲得し、そこにWhyOOPという名前のBookインスタンス
　を作る。
・Book WhyOOP には、上記インスタンスが存在するヒープ領域の
　ポインタが格納される。

そして、次に

　WhyOOP.setPrice("2400"); // WhyOOPに値段を設定する

というコードを書いたとしたら、これは次のことを意味します。

・メソッドsetPrice呼び出す。
・WhyOOPを指定する。
　つまり、WhyOOPインスタンスが存在するヒープ領域のポインタを渡す。
（Cのように明示的なポインタではないが・・・。）



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[オブジェクト指向再入門]　(5)Cは手動メモリ管理
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

しかし、下記の点でCとJavaとでは大きな違いがあります。

・Cでは、malloc関数で（サイズまで指定して）明示的にヒープ領域を
　獲得しなければならない。
・しかも、不要になったら、free関数で明示的にその領域を解放しな
　ければならない。


ここに2つの問題があります。

（１）他のヒープ領域まで侵入できる

Cではヒープ領域のポインタを明示的に扱えるため、自分が獲得
したヒープ領域を超えて、他のプログラムが獲得しているヒープ
領域まで参照できてしまいます。
したがって、Cでは他のプログラムが獲得しているヒープ領域のデータを
破壊するという重大なバグが発生しやすいのです。


（２）メモリ解放漏れバグ

メモリ解放漏れのバグもしばしば発生します。
特にイレギュラーなケースでメモリ解放を忘れがちです。

しかも、メモリ解放漏れのバグは見つけにくいのです。
多少解放漏れがあったとしても、プログラムを数回流した程度では、
メモリは枯渇しないからです。

つまり、通常のテストでは正常に動いていたのに、少しずつ使用可能
メモリが減っていって、長時間稼動させると妙な動きが始まるのです。
その解放漏れがレアケースにのみ通過する部分にあったりすると、
デバッグは困難を極めます。

一方、JavaなどのOOP言語ではヒープ領域の獲得と解放が自動化
されています。この自動解放の仕組みがガベージコレクションです。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[オブジェクト指向再入門]　(6)メモリ自動管理の唯一の弊害
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

メモリ自動管理はプログラマの生産性を向上させました。

これはOOPに限ったことではありません。
多くのWindowsプログラマがCやC++ではなく、VBを使う理由は、
VBの方が生産性が高いからであり、その生産性の高さの大部分は
メモリ自動管理によるものです。


しかし、メモリ自動管理には、たった一つだけ弊害がありました。

プログラムが動く仕組みをプログラマがイメージしにくくなったと
いう点です。

Cのプログラマは頭の中でメモリ領域をシミュレートしながら
プログラムを書いていました。

しかし、JavaやVBや.NETのプログラマの頭の中ではメモリ領域の
シミュレーションは行われていないでしょう。

そして、普段はそれでいいのです。

しかし、ときどきは必要になるのです。


したがって、私はOOPにおけるメモリの使い方の話をもう少し続けようと
思います。




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

次回発行予定は、2月初旬です。

乞うご期待！！



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

本メルマガは2003年12月8日に創刊されました。
創刊号 http://www.kei-it.com/sailing/01-031208.html で述べたとおり、
本メルマガのコンセプトは「読みものとしても面白い慶の事業計画」であり、
目的は「事業計画の背後にある基本的な考え方を語ること」です。

したがって、第一の読者としては、慶の社員（正社員・契約社員）及び
慶と契約している個人事業主を想定しています。

また、多くのソフトウェア会社・技術者が直面している問題を扱っているので、
ソフトウェア会社の経営者、管理者、技術者にとっても参考になると思い、
第33号(2004年7月19日号)からは「まぐまぐ！」で一般の方々にも公開する
ことにしました。
「まぐまぐ！」での読者数は2007年1月19日現在、649名です。


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

（以下をそのまま転送するだけです。）
---------------------------------------------------
【お勧めメルマガ　ソフトウェア業界　新航海術】
⇒ 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
（但し、knextall@kei-it.com には直接配信しています。）


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

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


☆筆者の趣味のブログ：身近にいる小動物の図鑑☆
　http://kei-it.tea-nifty.com/small/