この記事の内容とか
というのを読んで、オブジェクト指向ならちょっとだけ長いので私も書いてみようと。
文長いよ、という人は強調の部分だけ読めば、だいたい意味が通じるはずです。
That's M's format!
オブジェクト指向って誤解招くよねとか
オブジェクト指向って言葉自体が誤解招く言葉だと思いませんか。
たぶん皆様が戦われているのはオブジェクト指向ではなくてオブジェクト指向言語です。
たとえば私がオブジェクト指向に初めて触れたのは「オブジェクト指向方法論ＯＭＴ」という本でした。
以下、記憶違いだったらごめんなさい。
この本はオブジェクト指向言語を方法論として逆輸入した内容で、この中で記載されていた三原則が
- カプセル化
- 多様性、多態性（ポリモーフィズム）
- 継承
の３つで、この頃のオブジェクト指向ってのは３原則だったのねーって感慨が。
言語より先に方法論を学ぶという謎の学習順だったため、オブジェクト指向と言われると先に方法論が浮かんでしまうというレアな存在。
そのせいで、オブジェクト指向言語だけをターゲットとした話なのにオブジェクト指向と言われると、もやっとしてしまうお年頃です。
ちなみに私のオブジェクト指向言語初体験はその直後にやったTurboC++だったりします。
オブジェクト指向言語の原則とか
この３つの原則を説明するわけではありません。
そもそもこのポエム開いた人が知らないわけないでしょうし。
そんな原則になんのメリットがあるの？
なんでそんなものを原則と言ってるの？
という点を説明したいと思います。
何のための３原則なのかとか
この原則って、つまりところ構造化言語の問題に対する解決策なのですよ。
と、どこかの原理主義者から大量にマサカリが飛んできそうな発言をしてしまいましたけど、論理的な話や経緯はともかく、高級言語→構造化言語→オブジェクト指向言語と流れた現場の人間にとっては真実です。
CとかPASCALとかって構造化言語は非常に便利な反面、問題も多いものでした。
たとえばライブラリロードしたら、そこで使用されている関数名と同じ関数名は定義できません。
そのため、関数名はひたすら長くなっていきます。
たとえばWin32APIのGetPrivateProfileSectionNamesなんて関数名、正気を疑いますよね。
しかもパラメータは全て引数で渡す必要があるため、引数の数も多くなります。
たとえばWin32APIのCreateWindowEx、引数が12個もあるんですよ。おまけにExがついていない、引数が11個のCreateWindowと別にあるという。
CUIが主体の頃は、それでもなんとかなっていたのですが、これがGUIになった瞬間、崩壊。
9割同じでも、ちょこっと違う処理でも別の関数、別の名前。
引数がchar*でなくてintだと別の関数、別の名前。
便利なライブラリがあると飛びついてみれば、関数名がバッティングして使えない。てめこのやろ変な名前でdefine切ってるんじゃねーよ！的な何か。
リファレンス引いたりヘッダで引数調べる時間のほうがコード書く時間より長いとか、やってられませんよね！
そこで颯爽と登場したのがオブジェクト指向言語。
構造化言語でみんなが困っていたことが「原則」で全て解決したのです。
実際に解決した内容とか
・カプセル化
クラスが異なれば同じ関数名つけても問題ないので、関数名を長くする必要がありません！
・多様性、多態性（ポリモーフィズム）
引数の型が違っても同じ関数名つけられるので、関数名が短くなり、覚えなければならない関数の数も激減しました。
・継承
ちょこっと違う、似たような処理なら継承でどうにかできるようになりました。特にボタンなどのGUIパーツが楽になること楽になること。
こんな楽になるなんて、と当時構造化言語でひいこらGUI書いてた人は随喜の涙を流したという。
最後にぶっちゃけるとか
再生産性とか飾りなんです。一応基底クラスからの継承というのは再生産性なのですけど、自分でコードを書くときに再生産性意識したりはしないんです。それでも便利なんです。みんなハッピーなんです。
もちろん、全てが良かったなんてことはなくて、その後に潜在的メモリリーク・リソースリーク問題とか新たな問題が沸いたりするのですけど、それはまた別のお話。