Java言語でのデザインパターンで若かりし頃の未熟さを振り返る

良いプログラムを書く為にはどうすれば良いのか!?

「良いプログラム」の定義もそれぞれですが、先人が書かれた良書にはヒントが残されています。

その筆頭となる良書の一つが「リーダブルコード」ではないでしょうか。

プログラマーの五感を活性化させるリーダブルコードという良書

また多くの方が進められる良書に「GoFのデザインパターン」があります。

TaNA
私も初めて触った言語がJavaで、新人時代は愛読していました。ただ今思い返すと、殆ど理解できず、実践的に使えてなかったなぁ~。今改めて見返してみると「なるほどねぇ~」と分かる部分も多いのですが。

デザインパターンを知れば、保守性・再利用性の高いコードが書けるかもしれません。

デザインパターンとは!?

テクノロジーの世界でGoFと呼ばれる4人の賢者がまとめてくれた23種類のパターン。

過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し、名前をつけ、再利用しやすいように特定の規約に従ってカタログ化したもの。

それぞれのパターンは、プログラマーの間で何度も繰り返し考え出されたものであり、最善の解決策では無くとも、問題に対するトレードオフを考慮した典型的な解決策になっています。

Java言語で説明された書籍ですと、結城先生が書かれたこちらが有名です。

ちなみに昨今ではPHP・Ruby・Swiftなど言語別に参考書が発売されている模様。

またマルチスレッド用のデザインパターンは難易度が少し高め。

デザインパターンの目的は!?

良いプログラムの特徴に保守性が高く、クラス間が疎結合で再利用性が高い事が挙げられます。

それを実現させるために、一体どのような事を考えれば良いのか!?

POINT抽象クラスやインタフェースを活用して、クラス間を疎結合にすること!!

具体的なクラス名をプログラム中に書いてしまうと、クラス間の結合が強くなり、部品として再利用性が低くなってしまうなど、具体的な事例とそれに対する解決策が詳細に説明されています。

クラス間が疎結合で部品として再利用性が高いと何が嬉しいのか!?

・単体試験がやりやすい.

・疎結合でバグ調査がやりやすい.

・他の開発者と役割分担しやすい.

プログラムを書いて思ったのは上の点。

折角素晴らしい参考書ですから、読むで終わらず、一度は書いて処理の流れを把握してみました。

Java言語でのデザインパターン – サンプルロジック

後半のパターンはクラスも多くて大変ですが、印象深いパターンを幾つか抜粋。

処理の枠組みを集約 – template

スーパークラスで処理の枠組みを作り、サブクラスで具体ロジックを実装するパターンです。

新人の頃に初めて見た時、コードからif文がバッサリ消えて、結構感動した記憶があります。

ただどの処理をスーパークラスで書くかは悩みどころで、Bulderの方が潰しが効く気もします。

バッチ開発等で似た処理を何本も作る場合には大きな力を発揮した記憶があります。

クラス束縛からの解放 – factory

templateパターンをインスタンス生成に適用したパターン。

newによるインスタンス生成をメソッド呼び出しに変え、クラス束縛を解消するパターンです。

TaNA
若い頃、所構わずnewしまくっていたら(今でも結構やります)、先輩から「DI、DI」とよく怒られてましが、当時は何が困るのかよく理解出来てませんでしたが、単体試験を書き出すと次第に何となく理解できました。

DIはこちらの記事が参考になると思います。

DI・DIコンテナ、ちゃんと理解出来てる?

DIコンテナは多くのフレームワークにデフォルト実装されてます。

が、最近使っているCakePHP3は未実装、バージョンが4になっても当分実装されない模様orz

機能と実装の分離 – bridge

いかにクラス間の結合を緩くできるか!?

これはデザインパターンの命題かなと感じますが、「委譲」の素晴らしさが分かるパターン。

POINTJavaでの委譲はあるメソッドの処理を他のインスタンスのメソッドに任せること!!

機能と実装を独立させることで、互いに独自に拡張ができ、それを実現するため委譲で橋渡し!!

再帰プログラム – composite

いわゆる再帰プログラムです。

サンプルではファイルとディレクトリの関係を実装していますが、両者を同一視するパターン。

TaNA
正直再帰処理なんて使うの!?と思ってましたが、友人が転職活動時に面接で「再帰的なプログラム書いて」と言われた事があったそうです(怖っ)。

また基本情報でも出てくるアルゴリズム(確かクイックソート)でも、出てきた記憶があります。

知っておいて損はないパターンかなと。

たらい回し – chain of responsibility

オブジェクトを鎖のように繋ぎ、順次渡り歩いて目的のオブジェクトを決定するパターン。

誰かやってくれるだろう…と、まさに事なかれ主義的なパターンです。

たらい回しと聞くと負のニュアンスを感じますが、初めてコレ見た時は「スゲェー」と思いました。

ただクラス間が疎結合で、if文が消え、柔軟性が高い反面、処理が遅くなる事も考慮も必要。

インタフェースと委譲活用

とまあ色々書きましたが、隣に本を置いて日頃から意識してないと活用が難しいですね。

新人時代はとにかく抽象クラスを作って、そこに何でも詰め込んでいました。

結果、なんだか物凄い神的なクラスが出来上がり、痛い目にあった事も(;^_^

POINTまずはインタフェースと委譲を上手く活用する事を意識!!

改めてデザインパターンを見直して、これが活用のための第一歩かと感じます。