株式会社ベルクロップ

オブジェクト指向

世の中に本は数あれど、どうしてみんな車が好きかな。家が好きかな。
あの手の本を読んだら「オブジェクト指向」は今の自分でもよくわからなくなる。

オブジェクト同士の相互作用としてシステムの振る舞いをとらえる考え方と難しい言い方をされるこれなのだが、自分では「役割分担のカタチ」だと理解している。
( ´∀｀)＜オレがこれやるからソレはおまえな。それでこの作業はうまくいく
これを実現したいがための解説用語だと思っている。
まず用語ありきではなく、まず意義ありき。

何をするものか実態も分らないまま便利さを訴えられても心に響くはずが無い。

ケーキ屋さんでホールケーキを作るのを例にして、4人で作業してみる。
全員がスポンジ焼いて生クリーム作って、デコレーションしてハコ詰めしてという作業をする形態はとらない。
A:( ´∀｀)＜オレスポンジつくる。出来たら言うから生クリーム塗ってな
B:(,,ﾟДﾟ)＜オレは生クリーム作り続けるから後は頼んだ。
C:(..´Д｀)＜わしデコレーション担当～
D:( ﾟωﾟ)＜箱詰めはﾏｶｾﾛ
っと、各人役割分担を行うと。
AはCにスポンジできた！と言って渡せばよく、BもCに生クリームできた！といって渡せばよく、Cは飾りオーケーといってDに渡せばよい。
Dが最後詰めれば一連の作業が完了するっという作業形態をまず作るのだ。

このとき各人から他のヤツラを見た時、各自の大まかな役割さえ分ればよくて、細かい作業は何を行うかまで知る必要は無い。
スポンジ担当が、生クリームの上に乗せられるイチゴの数を気にする必要はないのだ。
極端な話、Aからしてみると、イチゴを用意するのはBかCかDか知っている必要すらない。それでうまく回るのだから。
この役割分担っぷりが「カプセル化」である。

ちなみにこれらの各人はそのままクラスになる。「クラス設計」である。
そうした場合A～Dのそれぞれのクラスを使うヤツが必要になる。
クラス同士でメッセージの投げ合いをしている図を見かけるが、そんなコードなんざ現実的なわけはなく、コントローラーとも言うべき役割は必要なのですよ。
mainであり、ソレ専門のクラスであったりする。役割分担役割分担。
ソースコード上で実現する場合「呼び出し元」と呼ばれる者の登場～である。
こいつが彼らを動作を管理するのである。
(,,・ω・)＜Ａ！スポンジできたか！？
(,,・ω・)＜次Ｂ！生クリームは！？
(,,・ω・)＜何？できてない？ほな今回終了。
プログラム的には処理終了の流れとなった瞬間である。
もう一度リトライ。
(,,・ω・)＜Ａ！スポンジできたか！？
(,,・ω・)＜次Ｂ！生クリームは！？
(,,・ω・)＜よっしゃＣ！作れ！
(,,・ω・)＜最後Ｄ詰めたか！？
(,,・ω・)＜よし。ALL OKで終了だ。
この流れの中で、じつはこの呼び出し元はケーキの出来具合など管理もしていない。

しなくてもいいようにしておくのがオブジェクト指向的開発。
必要ならば監査役を新たに設けてＤの作業前後におけばよし。
これで各人の作業に何の影響もない体制がとれている。これがオブジェクト指向的開発の利点。

ポリモルフィズムはコード変更の作業量を減らすための手段であり、いわゆる「設計の形式」種類を増加させないようにするための手段に応用できる。
継承も同様で「ちょっとずつちがういろんなもの」を効果的に表現というかコードで表すための手段である。
「よりやりやすく」「より効率的に」の手段である類ものなのだ。
役割分担が終わった後に行う、作業効率向上のための手順の標準化とでもいえば聞こえがよいか。

まず結論を示す。
それを誘導する言葉が紡ぐと。
それがない。
オブジェクト指向は便利だ！
こんな用語がある！
クラスと継承はこんなのだ！
車から乗用車とトラックが生まれるのがポリモルフィズムだ！
っと専門用語たっぷりで言われても訳分りません。

近年ではエセオブジェクト指向論者がいて、エセモデラーがいて、専門用語だらけの難解きわまる文章を書いているのが増えてます。
専門用語だけなら私は迷う事はあまりありませんが、書いてる内容が
( ･ω･)＜ｵﾏｴ絶対に理解してないやろって内容の記事を見るたびに少々複雑な気持ちになるものです。

良書に当たるか、よい技術者に巡り合う事は運もありますが大事なことかもしれません。