デザパタ本を読みました

　今の時代、classを使ってコーディングしていくことは当たり前の時代ですが、結局「オブジェクト指向プログラミング」って何？拡張(extends)とか実装(implements)とかすると、コードを読むときにあっちこっち行ったりきたりしないといけなくなるから可読性悪くなるだけでしょ。。。と思っていました。

　一応大学生の時にJavaを使ってグラフィカルなオブジェクトを画面に配置させて動かしたりしながら、オブジェクト指向を学ぶ講義があったのでなんとなく、ざっくりとしたイメージは持っていました。ところが実際に仕事でプログラミングするようになって、オブジェクト指向プログラミング(OOP)の何がそんなにいいのか分からないままでした。

　と言うわけで、OOPとはなんぞやと言うことを実例付きで解説してくれる本である「Java言語で学ぶデザインパターン入門」を読んだ感想を書いていこうと思います。

　このデザインパターンに沿ってプログラムをするためにOOPを使うのかなーと言う認識です。プログラムは今後機能を拡張、変更、修正していくものであると言う前提に立って、最初から拡張、変更、修正しやすいようなプログラムを書く、プログラムの一部を再利用しやすいようにするのがデザインパターンの目的の一つとのことです。

　デザインパターンを理解するときに必要なことは登場人物に役割を与え、その登場人物たちがそれぞれの役割を演じることで意味あるものを作り上げるイメージを持つことです。おそらく僕は、自分(プログラマ)が道具(クラスや変数、関数)を使って何か意味あるものを作り上げるイメージを持っていたため、

結局「オブジェクト指向プログラミング」って何？拡張(extends)とか実装(implements)とかすると、
コードを読むときにあっちこっち行ったりきたりしないといけなくなるから可読性悪くなる

と感じていたのかもしれません。登場人物を定義して、それぞれが自立して動いていく様を自分は斜め上から眺めるイメージを持つことが、OOPないしデザインパターンなのだと思いました。

　23個あるデザインパターンの1つであるFactory Methodパターンは複数インスタンスを生成する必要がある場面で、そのインスタンス生成をFactory(工場)が行います。本の中では身分証明書カード(IDCard)を作る工場(IDCardFactory)を題材とされていました。

　FactoryとProductクラスを継承することで、工場がインスタンスを生成する大まかな流れを定義することができます。このように処理の大まかな流れをスーパークラスに定義しておいて、実際にやりたい内容に合わせて少しカスタマイズするやり方をTemplate Methodパターンと言います。ここでいうTemplateの部分はFactoryとProductの関係です。実際にやりたい内容は、IDCardを作ることで、これはIDCardFactoryとIDCardクラスが担当します。Factory MethodパターンはTemplate Methodパターンを「インスタンスを生成する」という目的に合わせて応用したものと言えます。

　抽象クラスを見ると、Factoryはcreate(), createProduct(), registerProduct()ができること、またProductではuse()ができることが主たる役割なのだと理解できます。それはそのサブクラス達も同じです。という風に考えると拡張も意義があるなあと実感できました。仮にIDCardじゃなくても、似たようなもの例えば、PointCardを後から作りたいときにも応用できますね。

　多分、手続き型思考だったら、このIDCardを使う外側のクラスにメソッドとして、createIDCard()を作ったりしているんだろうなーと思います。IDCardデータクラスは作ってもIDCardFactoryクラスを作る発想にはならないですね。そうするとその外側クラスの中にはIDCardを扱う部分以外のメソッドやフィールドも当然あるわけで、結構コードがごちゃつきそうだなと感じました。

　書いた人、読んだ人共にデザインパターンを勉強している必要がありますが、あえて抽象クラスを切ることで、実装者の意図を伝えることができ、場合によれば読みやすいコードを書くことにつながるのかなと思いました。

　とりあえず、本を一通りさらっと読むことはしましたが、23個全てのデザインパターンを覚えるというか、一つ一つ噛み締めながら、自分でコードを書いてみないと身につかないので、練習問題をやっていきたいと思いますー！