はじめに
こんにちは。孔子の80代目子孫兼アプリケーションサービス部の孔です。今回のシリーズはデザインパターンに関するシリーズです。初めてデザインパターンを耳にしたのは2年前位になりますが、その時はエンジニア歴１年目で、100%理解するにはやっぱり経験値が足りませんでした。2年前のリベンジのため、再度勉強をやり直し、そのアウトプットをブログで残していこうと思います。
今回のシリーズは以下のような構成で進めていこうと考えています。
第1章. 基礎知識の紹介
そもそもデザインパターンとは何かおよびオブジェクト指向プログラミングとその関連知識（ex. Classとは何か）についてみていきます。
第2章. SOLIDとは何か
オブジェクト指向の設計原則、SOLID原則について、それぞれの原則がどのようなものかを説明します。
第3~5章. デザインパターンの紹介
デザインパターンを生成、構造、振る舞いに分け、それぞれのデザインパターンを何個かピックアップして紹介します。3章では生成、4章では構造、5章では振る舞いのデザインパターンを紹介します。
デザインパターンを理解するには、オブジェクト指向に関する知識がベースとして必要になりますので、デザインパターンを紹介する前にオブジェクト指向に関する話をまずしようと思います。1~2まではオブジェクト指向の話となりますので、もしすでに知識をお持ちの方は3章からのデザインパターンから、もしくは気になるパターンだけ読んでいただければと思います。
かなり長期連載になると思いますが、頑張っていきます！
デザインパターンとは何か
それでは、これからの学習目標であるデザインパターンとはそもそも何かについて紹介します。
デザインパターンは、一言で言うと「一般的に実装されるプログラムに対して繰り返し利用できるソリューション」です。
例えば、ECサイトで注文を管理するプログラムをみなさんが作るとします。そのシステムを最初から設計・実装しても良いですが、世の中にはすでに似たようなプログラムをたくさんの開発者が作っています。毎回毎回、どのように実装するかを考えたり、どのように作れば無駄のない・セキュア・可読性が良い…などなどが考慮されたプログラムとして設計できるかを考えるのは、とてももったいないですね。
そこで「注文を管理するようなシステムは一般的にこのような構成で作ったらいいんじゃない？」と誰かが定義したら、みんなそれを参考に作れば、多くの工数を節約することができます。この「一般的にこのような構成」に該当するのが、デザインパターンとなります。
デザインパターンは元々建築業界で使われるものだったそうです。アーチや庭、本館などを作る時に、それぞれの大体のパターンを作成しておき、それを組み合わせることで一個の建築物を作ってたのを、Christopher Alexanderというエンジニアがこれをソフトウェアに適用してみたらどうか！と思って誕生しましたようです。今や、IT業界では一般用語として幅広く使われる概念となります。
なぜデザインパターンが必要か
先ほどの話で「すでに誰かパターンを作ってくれたから工数が節約されそう〜」と思うかもしれませんが、メリットをもう少し考えてみましょう。
小さいプログラムを作るときは特に問題ないですが、段々作るプログラムが大きくなるにつれて以下のような問題が出てきます。
- なんか同じコードを何回も書いてるような気がする…
- 書いたのはよかったけど、バグが発生してどこが問題なのか探すのが大変…
- 実装中に要求事項が変わってコードを修正しないといけないけど、これ変えたらあれも変えないといけないや…
などなど、考慮点が多くプログラムも複雑になるため、さまざまな問題が開発中に発生します。そこですでに同じことで悩んでいた先人の知恵を借り、セキュア・変更に強い・DRYな・などなどが考慮されたプログラムを省エネルギーで設計することができます。
と思うとデザインパターンさえ覚えておけばどんなプログラムでも簡単に作れるのか！と思うかもしれませんが、そうにはいきません。デザインパターンを使いすぎると、むしろプログラムが複雑になって、可読性や修正が難しいプログラムにもなりかねます。
大事なのは、プログラムを作る際に、どのデザインパターンを、どこで適用するか、を正しく判断することです。
最後に
デザインパターンが何かおよび利用する理由がイメージできたらよかったかと思います。次回は「オブジェクト指向プログラミングとは何か」についてみていきます。それでは、次回もよろしくお願いします！
シリーズ一覧
- 第1章：デザインパターンを学ぶための基礎知識
