オブジェクト指向の壁

今回は少しITの専門的な内容です。
年季の入ったIT業界人、特に実装から離れたマネジメントの方々にとって”オブジェクト指向”というのは１つの大きな壁です。

判ったようで本質的なところが理解できなくてモヤモヤしている人が意外と多い。私もそんな一人です。
今後のITキャリアに悩む年配者のために、今日はそのオブジェクト指向プログラミングを多少なりとも理解するためのヒントを一緒に考えたいと思います。

※写真はオブジェクト指向プログラミングの父と言われているアラン・ケイ氏

よくあるオブジェクト指向の書籍

私も何とかオブジェクト指向とは何か？を理解しようと思い、何冊かの本を購入して、実際Javaのプログラムを体験したりもしてみました。

オブジェクト指向とは切っても切れない、継承、カプセル化、クラス、インスタンス　等の言葉の説明やそのプログラミングの方法を一生懸命学んだつもりです。

しかし、どうしても腑に落ちない。

大規模システムの生産性を上げるとか、保守性を高めるとか、そんな視点でオブジェクト指向を理解しようとしてもダメでした。

一生懸命Javaの文法を覚えて実践してみても、オブジェクト指向の本質は理解できなかったのです。

これは一体どういうことなのでしょうか。

オブジェクト指向の壁にぶち当たりやすい人

SE志望の新入社員が最初からオブジェクト指向型言語を学んで果たして本当に理解できるのだろうか、という疑問はありますが、今回はその議論は置いて、経験者や年配者の視点で考えていきます。

どんな人がオブジェクト指向の壁にぶち当たりやすいのでしょうか？

それは、従来の手続き型プログラミング言語に慣れ親しんだ人、代表的なものがCOBOLやCを使ってバリバリ開発していた人で、JavaやPythonが出て来た時には既に現場から離れてしまった人、そんな方々が挫折しやすいというのが私の推測です。

それは自分がまさしくそうだったからです。

開発の実体験が無いので当たり前と言えばそれまでなのですが、昔馴染んだ手続き型プログラミングの理解をそのままオブジェクト指向型に当てはめて理解しようとしていることも大きな理由だと思います。

そもそもなぜこれらのオブジェクト指向型言語が生まれて来たのか、なぜ手続き型言語だけではダメになってしまったのか、その背景や理由を知らないと実体験があったとしても壁にぶち当たる可能性が高いです。

では、オブジェクト指向型プログラミングがその生まれた時代背景にはどんなことが起こっていたのでしょうか？

手続き型プログラミングの限界

従来からの手続き型プログラミングには典型的な処理パターンがあります。超簡単な絵にすると以下のイメージです。

何らかのインプットデータを、ある条件やパラメータに従い、アウトプットデータに変換する、というものです。
例えば、所得税の計算をするプログラムは、以下の様な処理構造モデルで説明できます。

・インプット＝年収
・条件/パラメータ＝各種の税金控除条件や税率
・アウトプット＝所得税額

極論すると、どんな複雑で巨大なシステム、例えば銀行の勘定系システムでもこのモデルに当てはめて設計し開発が可能です。

しかし、近年のソフトウェア開発の対象物は、こうしたモデルに当てはめて開発できる範囲を越えて拡大してきました。

その特に大きな変化はゲームソフトの様な複雑なアプリケーションソフトウェアの登場です。

皆さんの多くはご存じだとは思いますが「ストリートファイター」とか「鉄拳」など様々なキャラクターが登場する対戦型格闘ゲームを思い起こしてください。

ゲームをする人同士が相手の動きを見てコントローラーを使って様々な操作をインタラクティブに行い戦い勝ち負けを競うものです。

このソフトウェアを手続き型言語で開発したらどうなるでしょうか？

例えば、コントローラーの右ボタンを押したらキャラクターがキックし、それを受けた相手キャラクターは、If 防御していたらダメージ無しで、else 防御していなければダメージ50をライフポイントから減算して・・・・・、考えただけでも恐ろしいことになりそうです。

そもそもこの様なリアルタイムかつインタラクティブな動作をシミュレーションする様なプログラムは、処理の順番を事前に定義できるものではありません。

無数の条件を抽出してインプット・アウトプットの処理をモデル化することは不可能です。従って手続き型プログラミングで開発しようとしても到底無理です。

では実際どのように開発されているのでしょうか？

私はずっとこれが疑問だったのですが、オブジェクト指向の教科書を読んで初めてその一旦を知ることができたと感じました。

オブジェクト指向型プログラミングで可能になったこと

(1) クラス、そしてフィールドとメソッド

ゲームに出てくるオブジェクト＝戦闘キャラクター、コントローラ、戦闘の場所、を１つ１つの”クラス”というものにして定義できます。C言語で似たような機能をあげるとしたら”関数”や”サブルーチン”の塊とでも表現できるでしょうか。

クラスはアプリケーションを動作させるための実体物を、そのイメージ通りに定義できることが大きな特徴です。

クラスには属性部（フィールド）と操作部（メソッド）があり、例えばフィールドには戦闘キャラクターの特性（性別、身長体重、国籍等）やライフポイントを保持する変数、メソッド部にはその戦闘キャラクターが持っている「技」の数々の操作を定義します。

そうすることで例えば、少林寺拳法をベースにした戦闘キャラクターのクラスを定義しておき、そのクラスを下敷きにして酔拳（ジャッキーチェンの映画で有名）ができる戦闘キャラクターを少ないコードを追加するだけで作り出せるようになります。これを継承と呼び、オブジェクト指向型言語の重要な機能です。

(2)クラス間通信

メインの処理が手順や条件に従って逐一命令を実行するのではなく、クラス間でのやり取りによってでも相互に処理を呼び出したり変数を書き換えたりできるようになります。

戦闘キャラクター間のバトルはこのクラス間でのやり取りで柔軟でかつインタラクティブな処理（動作）が可能になるのです。

これは手続き型プログラミングではできなかったことです。

(3)クラスとインスタンス

手続き型プログラミングではあらかじめ変数の定義を行う必要があります。

これは巨大なデータ構造を取り扱ったり多数の処理を扱うための巨大なメモリ空間をあらかじめ確保することになります。
以前私が生産管理システムを開発した際、何万件ものデータを一旦メモリに格納するために、１万行もの変数配列を定義したプログラムがありました。これをコンパイルすると実行ファイルが２GB以上になっていたことを覚えています。

しかしこれ、オブジェクト指向であれば、最初から巨大な変数配列を用意しなくてもよく、PGが必要になった都度インスタンス化（メモリロード）すればよいことになります。

これは巨大なサイズのゲームプログラムをメモリ空間が少ない安価なゲーム機でスムーズに動作させるためには重要なことです。

戦闘キャラクターを何度入れ替えしてもその都度メモリを開放しロードすればよいのですから。

まとめ

オブジェクト指向型言語の全体像を知るにはさらに多くの概念や言語仕様について学ぶ必要がありますが、今日はここまでにします。

それでも今回、手続き型プログラミングとオブジェクト指向型プログラミングの違いをその生まれてきた理由と共に理解することができれば、オブジェクト指向の壁を乗り越える大いなるヒントになるのではないでしょうか。

私もビジネスでこのオブジェクト指向を有効活用するために、さらなるStudyをしていきたいと思っています。

※最後に参考図書※
沢山の書籍がありますが自分にはこれが一番良かったです。
「スッキリわかるJava入門」 2019/11/15刊 中山清喬,国本大悟共著

〆