Qiita リンク
オブジェクト指向のいろは
https://qiita.com/nrslib/items/73bf176147192c402049
あとがき
オブジェクト指向について教える機会が多くありました。
そのたびに一から説明して、といったステップを踏んでいたのですが、これがいかにも効率が悪い。
ちょうど新卒研修の講師をやる予定があったので、ここで一旦まとめておこうとして作ったのが次のスライド群でした。
https://nrslib.com/oop-slide-1/
https://nrslib.com/oop-slide-2/
https://nrslib.com/oop-slide-3/
結果としてこれは新卒研修用という枠組みから広がって最終的には５０人規模の社内勉強会（講習会？）に発展しました。
ひとつのスライドの内容をプレゼンすると大体 45 分程度になるので、三回に分けてやったんですが、おおむね良いプレゼンができたとは思っています。
参加者にフィードバックを頂いたりもしたのですが、既に実践している方であっても改めて再認識したり、新たな気づきがあったようで自分としても満足していました。
ただ、問題がふたつありました。
ひとつめの問題
ひとつめの問題は、スライドがプレゼン前提になっていることです。
最初はその問題にあまり気づいていませんでした。
勉強会が終わった後、折角よなべをして作ったスライドでしたから、ブログで公開しようかなーという気持ちになります。
そこで公開前にチェックがてらで見直しすると「細かいところまでは伝えきれないなぁ」と感じました。
講習会みたいな勉強会ですと、聴講する側はとても「受動的」です。
ですので、なるべく興味を持って聞いてもらうためにスライドも視覚的にわかりやすくするように仕上げたりします。
それは結果的に、要点をかいつまんで伝えるために情報量を落とすことになります。
それを補うのがプレゼンターの役目で、減った情報をカバーするべく補足や Tips を口頭で付け加えます。
この情報が結構大事。
そしてこの問題がふたつめの問題につながってきます。
ふたつめの問題
そのふたつめの問題というのが復習しづらいことです。
講義を受けると「分かった気」になってしまうことは多いです。
その場で納得してしまうと復習なんてしなくてもいいかな、と思うのが人の常。
もちろんこれはオブジェクト指向の入り口みたいなもんですとは補足はするのですが、記憶に残るのは「オブジェクト指向完全に理解した」という記憶だけです。
それでも実践に活かせるのであればよいのですが、しばらく後に受講者と会話したり、コードレビューを行ったりすると、あまり伝わっていないことが多かったです。
聞いただけで実践できるならだれも苦労はしないです。
もしも実践できたのなら、元々できていたか天才かのどちらかだと思います。
そういうわけで、実践できていないということに気づいたときにやっと人は「復習しよう」と思い立つのですが、そのときに資料がこのスライドしかないのです。
悲しいことにスライドはプレゼン向けなので情報量が落とされてしまっているため、細かい情報がありません。
その場合の対応策はプレゼンの内容を思い出してもらうことなのですが、記憶の底に沈んでしまっているのでかなり難しい。
解決法
といった感じでふたつの問題を抱えていると感じていたので、じゃあそれをカバーするためにはどうすれば？ 復習用に記事にしておけばいいか、というノリで書いたのがこの記事でした。
そう思って記事を書き上げたまではよかったのですがテーマの特性上異論が多く存在するだろうし、一家言をお持ちのエンジニアは相当数いると予想がついていたので、やはり公開するのはかなり勇気がいりました。
二日ほど経ったいまでも結構怯えています。
この感情はいつまで経っても慣れません。
記事の話
それはさておき記事の話をしてみましょう。
今回の記事はあくまで「いろは」ということで入門記事です。
これがオブジェクト指向のすべてです、などとは到底言えません。
実際内容的にも「オブジェクト指向は怖くないよ、こんなことができるよ、楽しそうでしょ、だまされたと思ってこっちへおいでよ」みたいな感じです。
なので説明してないことが多かったりします。
省略したこと
たとえば、わかりやすいところでいえば継承ですね。
継承は便利な反面、安全に利用するのが難しいテーマでそれを説明するだけでかなりの文章量になってしまい、論点がズレそうなので省きました。
もしも継承の具体的な話が知りたい場合はこんなスライドがあります -> https://nrslib.com/oop-slide-3/
（いつかこれも記事にしてみようかな）
アドホック多相とパラメータ多相についても省いています。
ジェネリクスとかオーバーロード、暗黙の型変換などなど結構言語によって実装の仕方にバラツキがあるのでいたしかたなし。
あとは本来のオブジェクト指向とかそこら辺の話も省きました。
とりあえず「オブジェクト指向を使えるようになってプログラミングを楽しんでほしい」というのが隠れテーマなので、興味が沸いたときに調べればいいと思います。実践してたらきっとそのうち興味が湧くでしょう。
ちなみに自分の考察では C 言語で既にカプセル化とポリモーフィズムみたいなことをやってたけど、ポインタとかその他もろもろ危なっかしいからどうしたらいいだろうね？ こうしたらいいんじゃない？ っていうアイデアから始まったと思っています。
つまりオブジェクト指向のアイデアを実現するためにカプセル化とポリモーフィズムが生まれたのではなくて、カプセル化とポリモーフィズムがすでにあって、そのアイデアを「安全に」行うためにオブジェクト指向というアイデアが生まれた。そんなイメージです。
当時を経験したわけじゃないので本当にただの考察です。
話がそれましたが、入門用記事として納得感を持ってもらえるように省略されている部分もあるのでその点ご留意を（これについては記事にも追記しておきました）。
解説内容
さて、肝心の記事の内容についてですが……どうだったんでしょうかねぇ。
難しいことは難しく伝えるのは簡単なんだけど、難しいことを簡単に伝えるのはやはり難しいです。
そもそもオブジェクト指向などという何十年も歴史があるものを、たった 40,000 文字程度の記事で説明しきるなど出来るはずがありません。
結果として一部内容を省略するに至るので、それはある意味誤魔化しでしょうね。
オブジェクト指向が何であるか、という問いも大真面目に答えると話が逸れそうで「抽象化」の一言で片づけてしまっています。
抽象化して、抽象的に扱う。
カプセル化して、ポリモーフィズムで扱う。
最も重要なのはカプセル化で、ポリモーフィズムはその扱い方と考えています。
ですので、カプセル化が重要ということでカプセル化に着目すると「抽象化」の話が主題になり、結果としてモデリングの話が色濃くなるでしょう。
オブジェクト指向の解説を行う記事の多くがモデリングの話になっているのはこれが理由かと。
他にはオブジェクトに着目するとメッセージングの話にフォーカスすることになるんじゃないかな。
結局みんな間違ったこと言っていないよなー、というのは常々感じています。
その中で初学者として納得しやすいのは、どの解説の仕方かな、と考え多結果であの構成になってたりします。
「抽象化したかったんだよ、関数だけじゃ足りなかったんだよ」みたいな。
恐らくカプセル化を重要視している方ほど、記事の構成と伝えようとしていることに違和感を感じると思います。
まとめ
言い訳もといあとがきとしてはこんなところでしょうか。
みんな大好きオブジェクト指向。
私もオブジェクト指向は大好きです。
今回作った記事が誰かの役に立てれば幸いです。
