Java デザインパターン総論 — 現場で本当に効くパターンの選び方

デザインパターンは 「暗記するもの」 ではなく、 「あとで変更が入ったときの逃げ道を、名前のついた形で先に用意しておく」ための共通語彙 だと捉えると、実装判断がブレません。

本連載では、Glossvation が業務システム開発で実際に有効と感じた GoF パターンに絞り、 JDK/Spring の中で既に動いている実例とともに整理します。

なぜ 2020 年代の Java でも学ぶ価値があるのか

Java 17/21 で record / sealed classes / パターンマッチングが入り、 「古典的な GoF パターンはもう要らないのでは？」という議論は確かにあります。 一方で現場で見ると以下の事情でまだ生きています。

• Spring のソースを読むのに必須 — BeanFactory (Factory Method), ApplicationContext (Facade / Singleton), JdbcTemplate (Template Method) など、名前からしてパターンそのものです- ドメインを言葉で切り分けるために有効 — 「ここは Strategy で差し替える」と言うだけで、他メンバーに意図が伝わる- 言語機能で置換可能なものと、そうでないものを見分けられる — 例えば Singleton は enum 一発ですが、Visitor は現代でも必要です

パターンを選ぶときの判断基準

経験的に、以下の順で考えるのが安全です。

優先度	判断軸	具体例
1	言語機能で済むか	Singleton → enum、Immutable DTO → record
2	フレームワークが提供しているか	DI 済みなら Factory を自作しない
3	変更の軸は何か	商品種別が増える → Strategy / Factory Method
4	チームの読める共通語彙か	Visitor は強力だが読み手を選ぶ

本連載で扱うパターン

実務での登場頻度順で以下を取り上げます。

生成に関するパターン

• FactoryMethod — 生成の型を抽象側に委譲する
• AbstractFactory — 関連する複数オブジェクトをまとめて作る
• Builder — コンストラクタ引数が 4 つを超えたら
• Prototype — 「型 + 設定済み」 を複製する
• Singleton — ただし enum を推奨

構造に関するパターン

• Adapter — 既存 API を新 API に馴染ませる

振る舞いに関するパターン

• TemplateMethod — アルゴリズムの骨格と差分の分離
• Iterator — Java では Iterable 実装でほぼ事足りる

アンチパターン: 「パターンありきで設計する」

デザインパターンを覚えたてのころに陥りがちなのが、 変更要件もないのに Strategy や Factory を導入してクラスを増やす こと。これは可読性を落とすだけです。

目安としては:

• クラスが 1 種類しかない → 抽象化しない
• 変更が入る可能性が明示されている → パターン適用を検討
• 既に 3 種類以上の分岐が if / switch で書かれている → パターン化を検討

「抽象化できる」と「抽象化すべき」は違います。 使うタイミングを間違えなければ、 コードは必ず読みやすくなります。

---

次回以降は各パターンの実装・JDK や Spring 内での具体例・ハマりどころを掘り下げます。