自分がもし人に「Python使えよ。捗るぞ」って言うなら

（http://blog.bagend.info/2011/09/cobolerpython.html）の続き

長い間コピペでプログラム作ってる人間の立場で、オブジェクト指向の本読むと「クラスって何で必要なの？別に作らなくてもいいよね」って感想になる。

思想としてのオブジェクト指向を解説した本（昔はこういう本ばかりだった）はもちろん、プログラミング言語の入門書も「クラスって何だろう？」「それではクラスを作ってみよう！」ってコンボで書かれているので、戸惑いはなおさらだ。

入門書に書かれているコードは、もちろん入門者向けなのでさしたる量もなく、工夫すれば（あるいは、工夫の必要もなく）オブジェクト指向でなくても実現できる程度の難易度しかなく「それってCOBOLでもできるよね！」という結論になりがちだ。金槌を持つ者には全ての問題が釘の頭に見える、という例えがあるが、与えられた仕事は（今まで通り）釘の頭を打つことなのに、なぜ使い慣れた金槌以外の道具を新に工夫せねばならないのか。

かくして、たまたま特定の言語しかサポートしていない、特定の環境を前提としたところだけ、その言語で作ればいいということになる。その言語がたまたまオブジェクト指向プログラミングをサポートしていたとしても、そうでない書き方もできるのであれば…。

自分が面白がって使うだけならともかく、他人に勧めることを視野に入れるなら、オブジェクト指向が解決（せめて軽減）しようとしている問題に対する共感がないと、その人が既に抱えている問題がこれで解決されるかもという期待が無いと厳しい。一般論としてはWikipediaの「オブジェクト指向プログラミング」の背景の説明があるけれど。

コピペで機能追加をやっていくと、機能の増加とともに既存の機能のコピーでしかないところの量もそれ以上に増え、次の案件でメンテすべきコードの量も増えていく。コピペによって倍々ゲームで増えていくコード、そのメンテ時間・費用の増加をユーザやマネージャといった立場の人たちがいつまで「ま、しょうがないよね」「かわりにプログラマの単価下げようよ」と甘受し続けてくれるのか。

そのような問題への打開策としてオブジェクト指向があるのなら、出発点として、まずクラスを作るところから始めるってのが、そもそもよくない。まずは自分で作るって発想だと、時間的金銭的メリットを実感できる、再利用のフェーズに到達するまで時間がかかる（≒メリットを得られないうちに頓挫する or 面白かったねで終わる）。

入門書のコードをそのまま打ち込んでるうちは、なんとなく良さそうに思える新機軸も、自分で設計するとなれば、理解のあやふやなところが一気にのしかかってくる。

しかし本来は、ともすれば何でもかんでも、それこそ標準ライブラリにあるような機能ですら自分で作ろうとする人に「遊んでないで、既にある物使えよ」と言うための発想だったはずではないか。

なので、自分がもし人に「Python使えよ。捗るぞ」って言うなら、まず標準ライブラリであるJSONのエンコード・デコードの実演あたりから始めると思う。もちろん、それだけだと「こういう標準ライブラリがあるよ、便利だね」で終了する。だから、自作のエンコーダを突っ込んで、標準ライブラリそのものを変更しなくても、そのカスタマイズができるんだよってところを中心にやる。自分でイチからロジックを書くのはもちろん、もうソースをコピペする時間すら惜しいのだと。

もっといい例はないかなぁ。その後はどう続くのかなぁ。

同じ機能を、クラスの利用ありとなしで実装して、それぞれのテスト範囲（テストコード）を比較するとか？