こんにちは森川です

前回は、序章として、「オブジェクト指向について書いてみたい」というタイトルで私の経験談を中心に書いてみた。

今回は、オブジェクト指向（ＯＯ オーオー）とはなんぞや？？というお題で書いてみたい。

ＯＯと比較するために、プログラムを関数を使いながら共通化できる部分や機能単位で構造化していく手法を構造化プログラミングと書くね。

構造化プログラミングではなくＯＯで設計すると何ができるようになると思いますか？？

ん～～～（悩）（悩）（悩）
・構造化プログラミングではできないことが可能になる？？？
・処理がぶち早いシステムが作れる？？？
・なんかかっこいい？？？

全部違います

答えは、品質が高いソフトウェアができる！！！

別にＯＯを使ったからと言って、特殊なことができるわけでもないし、処理が早くなるわけではないよ。
逆に処理速度を考えるなら構造化プログラミングで全部設計した方が早いんじゃないかな。

ＯＯの考え方について具体的に考えてみたいと思う。

例えば、こんなシステムを作ることを想定してみる。

「データベースからデータを抽出して、CSVに変換して出力する。」

普通によくあるよね。

Ａさんはこう考えました。

・CsvOperatorクラスを定義しよう。
・このクラスの中に「データベースからデータを抽出して、コレクションに入れ込むextractDataメソッド」を作ろう
・次に「データを入れ込んだコレクションからcsv形式へ変換するformatDataメソッド」を作ろう
・最後に「変換したデータを出力するoutputDataメソッド」を作ろう
・上記の3つメソッドを定義すればなんかいけそう

しかし、Bさんは更にこう考えました。
・もしかしたら将来的にカンマ具切りのcsvだけでなく、タブ区切りのtxtファイルへの拡張もあるかもしれないなぁ。

Cさんは更にこう考えました。
・もしかしたら、コレクションをcsvへ変換するときに、例えば「null」は 「Nan」に変換して出力したりするような変更が入る可能性が高いなぁ。

ここで問題です。
この 3 人の中で誰がＯＯで考えて設計しているでしょうか？

答えは、、、、、「Bさん」と「Cさん」です。
Aさんはクラスを定義しているだけでＯＯで設計していないです。

このCさんの設計をプログラムへ起こしていくと、私であればこう考えます。
「もしかしたら」の部分は今は実装しない将来必要があれば実装するというのは大前提です。

Bさんの設計のように将来的にcsv以外のtxtファイルへの拡張を考えたとき、おそらくデータを読み込むextractDataメソッドと出力するoutputDataメソッドは変化しない共通化できるだろう。
であればこれらは抽象クラスにまとめておけばよいよね。
でもCさんが考えるように、formatDataメソッドは変化するだろうから、なんらかの手をうっとかないといけない。
Factory Methodパターンのように、サブクラス側へおまかせする、または、Strategyパターンのように委譲を使って別クラスへおまかせする。
ＯＯの原理原則を考えると後者かな。

BさんCさんのように考えると、こんな簡単なプログラムでもAさんが設計したようにクラスは1つだけではすまなくなくなってくるんよ。
複数のクラスに分かれるし、抽象クラスやインターフェイスなどの構造化プログラミングではでてこない登場人物が出てくるんよ。

上記の答えはざっと考えたので正解かかどうか知らないし、私よりわかっている人から見れば違うよって怒られるかもしれない。
ここでは、正解しているかどうかはどうでもよくて、以下の2点に気づいてほしいんよ。

1. ＯＯと構造化プログラミングでは、プログラミングへの視点が全く違うということ。
2. ＯＯには構造化プログラミングではでてこない新しい知識が必要であること。

１についての解説
構造化プログラミングはシステムを構築している観点からプログラムを見ているんよ。
でも、ＯＯは、構築している時間なんてほんの一時期、これからシステムを運用していく時間の方が長いだろう。
であるならば構築している今ではなく、これから運用していく未来のことを考えないといけないだろう。
つまり、将来的にシステムを拡張、変更したときに不具合が起きるリスクは事前になるべく減らそうという考え方。

要は、ＯＯは運用の視点からプログラムを考えた、未来を見据えた設計方法。

だから一番初めて書いたように「品質が高いソフトウェア」ができるんよ。
プロのプログラマー、システム屋であるならばマスターしておきたいと欲求は起こりませんか？？

２についての解説
上記で偉そうにしったげに抽象クラスとかなんとかパターンとか書いたけど、これはわざと書いた。
動くシステムが作れるだからＯＯもできるだろうと思うのはそもそも大きな間違い！！
構造化プログラミングには上記のような登場人物は現れないし、なんとかパターンなんてでてこない。
要は、自分はまだまだ、新しい知識一から学習するんだという謙虚な姿勢が必要ということ。

ＯＯで書かれてあるコードを見て、なんでこんなに細かく区切るのだろうかとか、何をしているのか意味がわからないとか感じたことがある人は、おそらく上記の2つが足りていないから。

ＯＯを理解している人とは、JavaやC#のようなオブジェクト指向のプログラミング言語を完全に理解していることではないし、自分でクラスを定義できる人でもない。
上記で書いたように未来を想定してプログラムを設計できる人である！！

もう少し書きたいところではあるが、時間かかったので続きは次回にまわしたい。
次回も「オブジェクト指向（ＯＯ オーオー）とはなんぞや？？」について書いてみたい。

今日も一日がんばりましょう。