特徴ばかりがひとり歩きするオブジェクト指向

世のプログラマオブジェクト指向をどのように教えているだろうか?
下のオブジェクト指向の特徴を教えて終わりとしてないだろうか?


僕はこんなふうに教えるものだと思ってた。
「人と犬は走り方の違いがあるけど、どちらも抽象的には動物だし、走るよね。」
でも最近は違うと思うようになってきた。
(ほんとに今さらだ)


特徴を教えることはもちろん必要だ。
問題はオブジェクト指向の教育=特徴の紹介となっていることだ。
これがどんな問題をはらんでいるだろうか。


問題

抽象的な概念を構造化できない

User とか Page とか、学生でも具体的な概念が理解しやすい要素は問題ない。
問題は抽象的な概念だ。

たとえば HTTP には Cookie や Header や Parameter がある。
これらがどういうものかは Web 系プログラマーならわかるだろう。
これが初心者からすれば、Cookie も Header も Parameter もただの送信データ。

これを構造化しようとすれば、ごちゃ混ぜにしたりと悲劇が生まれる。
(もちろん HTTP は言語の標準ライブラリがあるだろうから自分で書く必要はないけど)


名前がつけられない

初心者にアドバイスをして、適宜抽象的な概念に分けるように促した。
一歩前進。


しかし初心者はすぐに詰まる。
抽象的な「それ」を何と呼んだらいいのかがわからないのだ。
彼らには名前候補のレパートリーがない。


適切な名前が付けられないから役割があやふやになってしまう。
適切な名前が付いているのにその意味がわからないから余計な機能をつけてしまう。


たとえば .NET では FileStream や MemoryStream の上位クラスに Stream があるという構造だけど、Stream なんてプログラマをやらないと出てこない概念だ。


解決策

基礎を学ぶ

これはこれから学ぶ人に対しての解決策。
残念ながら簡単な解決策ではない。


残業するなら勉強しよう でも書いたけど、僕は基礎学習が有効だと思う。
Web に関しては「Webを支える技術」を読めば間違いない。

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)


「資格は役に立たない」なんて言って何も勉強しないプログラマもいるけど、IPA情報処理技術者試験はよくできている。
僕はプログラマーになる前に基本情報技術者を取ったけど当時はよく分かっていなかった。 その後、開発経験と紐づいて初めて理解できて活用できたと感じた。


言語の標準的なライブラリに触れるのもいい。
さまざまなパターンの構造があり、学ぶところが多い。
名前づけの目安も身につく。


オブジェクト指向を意識させない

これは初心者をメンバーに入れる経験者側の解決策。


Rails をはじめとした MVC フレームワークはとてもよくできている。
この手のフレームワークでは、フレームワークが肩代わりしてくれる分、コードを書く量が少なく済むということは言うまでもない。

僕が素晴らしいと思うのは、「プログラマーの技量によってプログラム構造に極端な違いが生まれづらい」ことだ。


たとえば View のためのユーティリティは Helper という名前がついている。
あとは FooHelper の Foo の部分の名前だけ考えればいい。
アプリケーションの構造は既に出来上がっている。
大半の人は構造化を意識しながらプログラミングしなくて済むのだ。


そのうち一部の人はフレームワークに手を加えたり、全体像を構成したりできるようになる。


最後に

目的はプログラムを適切な大きさ・役割に構造化し、メンテナンスしやすくすること。 オブジェクト指向はあくまでも手段。
継承やポリモーフィズムはその表現方法に過ぎない。


よい構造、いわゆる読みやすいコードを書くために必要なスキルは、生まれ持ったセンスではなくて、IT技術のあらゆるレイヤーの知識や仕組みを吸収してきたかに尽きると思う。


オブジェクト指向」だけを切り取って教えることは敷居を下げるためには必要なんだけど、それだけだと困るよねという現場からの意見でした。


オブジェクト指向でなぜつくるのか 第2版

オブジェクト指向でなぜつくるのか 第2版

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)