https://tech.feature-branch.co.jp/tags/%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3/Recent content in デザインパターン on Feature Branch Tech BlogHugojaFeature Branch inc.Mon, 06 Jul 2026 18:48:25 +0900https://tech.feature-branch.co.jp/posts/2026/02/about-pattern/Tue, 03 Feb 2026 10:39:53 +0900https://tech.feature-branch.co.jp/posts/2026/02/about-pattern/<h2 id="はじめに">はじめに</h2> <p>今回はデザインパターン・アンチパターンについて話したいと思います。 まず、今回の趣旨を伝えておきます。 今回は「デザインパターン・アンチパターン」というものを「認知」していただければ成功かと思います。 この後、いくつか実際のパターンなども紹介しますが、すべて覚える必要はないです。また忠実に守る必要もないです。　　</p> <p>実際に問題に直面したときや、設計前などに、存在することを知っていれば、その時に詳しく調べればいいのです。 その助けになれば良いかなと思います。</p> <h2 id="1-プログラミングにおけるデザインパターン">1. プログラミングにおけるデザインパターン</h2> <p>デザインパターンとは、ソフトウェア設計において繰り返し現れる問題に対する、<strong>先人たちが積み上げた「再利用可能な解決策の型（テンプレート）」</strong> のことです。1994年に出版されたエリック・ガンマらによる書籍（通称：GoF）によって広く普及しました。 デザインパターンを採用する目的は、単に「コードを綺麗にする」ことだけではありません。以下の3つの質を向上させることにあります。</p> <ul> <li><strong>保守性</strong>: 修正が必要な際、影響範囲を最小限に抑えられる。</li> <li><strong>拡張性</strong>: 新しい機能を追加する際、既存のコードを壊さずに済む。</li> <li><strong>共通言語</strong>: 開発者同士が「ここはObserverで」と言うだけで、複雑な設計意図を瞬時に共有できる。</li> </ul> <p>有名なパターン（抜粋）</p> <table> <thead> <tr> <th>パターン名</th> <th>概要</th> <th>主な使いどころ</th> <th>メリット</th> </tr> </thead> <tbody> <tr> <td><strong>Singleton</strong></td> <td>インスタンスを1つに制限</td> <td>DB接続、ログ出力、設定管理</td> <td>リソース重複防止、状態の一元管理</td> </tr> <tr> <td><strong>Factory Method</strong></td> <td>生成ロジックをクラスに委譲</td> <td>OS毎のUI生成、プラグイン</td> <td>呼び出し側が具体名を知らずに済む</td> </tr> <tr> <td><strong>Observer</strong></td> <td>状態変化の自動通知</td> <td>イベント通知、SNS、MVC</td> <td>疎結合なリアルタイム連携が可能</td> </tr> <tr> <td><strong>Strategy</strong></td> <td>アルゴリズムの動的切替</td> <td>決済手段切替、ソート選択</td> <td><code>if/switch</code>文を排除し拡張性向上</td> </tr> <tr> <td><strong>Adapter</strong></td> <td>インターフェースの変換</td> <td>レガシーコードの再利用</td> <td>既存コードを壊さず新環境に適合</td> </tr> </tbody> </table> <br> <h2 id="2-プログラミングにおけるアンチパターン">2. プログラミングにおけるアンチパターン</h2> <p>アンチパターンとは、一見すると効率的または合理的な解決策に見えますが、実際には<strong>長期的には悪影響（保守性の低下、バグの増加、パフォーマンス劣化など）を及ぼすことが証明されている、避けるべき設計・実装の型</strong>のことです。 デザインパターンが「ベストプラクティス（最善策）」の集積であるのに対し、アンチパターンは <strong>「ワーストプラクティス（失敗の典型例）」</strong> を体系化したものです。 アンチパターンは、悪意を持って作られるものではありません。多くの場合、以下のような「一見正当な理由」から発生します。</p> <ul> <li><strong>知識不足</strong>: 適切なデザインパターンや言語のベストプラクティスを知らない。</li> <li><strong>短期的な効率</strong>: 「今は動けばいい」「納期が最優先」というプレッシャー。</li> <li><strong>文脈の誤解</strong>: ある場面では正解だった手法を、不適切な場面に無理やり適用する。</li> <li><strong>過剰な一般化</strong>: 将来使うかもしれないという憶測で、過度に複雑な抽象化を行う。</li> </ul> <p>有名なパターン（抜粋）</p> <table> <thead> <tr> <th>パターン名</th> <th>特徴</th> <th>弊害</th> <th>対策</th> </tr> </thead> <tbody> <tr> <td><strong>Spaghetti Code</strong></td> <td>複雑に絡み合った制御構造</td> <td>解読不能、修正の影響範囲不明</td> <td>関数分割、単一責任の原則を適用</td> </tr> <tr> <td><strong>God Object</strong></td> <td>一つのクラスに機能が集中</td> <td>保守性低下、修正時の連鎖バグ</td> <td>責任に応じたクラスの適切な分割</td> </tr> <tr> <td><strong>Golden Hammer</strong></td> <td>特定の技術を無理に適用</td> <td>効率低下、不適切なアーキテクチャ</td> <td>適材適所の技術選定と多角的な視点</td> </tr> <tr> <td><strong>Cargo Cult</strong></td> <td>理解せずコピペで実装</td> <td>不要なコード、予期せぬ挙動</td> <td>コードの意味を理解し、不要を削る</td> </tr> <tr> <td><strong>Magic Numbers</strong></td> <td>生の数値が直接記述される</td> <td>意図が不明、変更漏れの発生</td> <td>定数（const/enum）に名前を付ける</td> </tr> </tbody> </table> <br> <h2 id="3-データベース設計のアンチパターン">3. データベース設計のアンチパターン</h2> <p>データベース設計におけるアンチパターンとは、RDB（リレーショナルデータベース）の数学的基礎である「リレーショナルモデル」や「正規化理論」を軽視した結果、<strong>データの整合性、クエリのパフォーマンス、およびアプリケーションの拡張性を損なう設計</strong>のことを指します。 DBの構造は一度運用が始まると変更が非常に困難（破壊的変更になりやすい）なため、設計段階でこれらの罠を回避することが極めて重要です。</p>