デザインパターンについて

デザインパターンは重要だ。 いくら勉強しても、時にはパターンに違反したり、間違った組み合わせ方をしたりして、非効率なコード構造を作ってしまうものだ。だから、継続的に見直し、悩み続ける必要がある。

作っていると、自分でも気づかないうちに、すでに何らかのデザインパターンを適用していることが多い。 しかし勉強すべき理由は、自分の思うままに作ったものは、たいていどこかに穴があったり、非効率である確率が高いからだ。デザインパターンは数多くの開発者たちが長い時間をかけて一緒に練り上げてきたパターンであるため、次のような利点がある。

1. どんなパターンかを知っているだけでも、ある程度実装の形がわかる。 → 開発者同士のコミュニケーションが楽になる。ここでいう開発者たちとは「過去の自分」も含まれる。
2. 効率的だ。数時間ちょっと考えて作った構造ではなく、歴史的に長い間練り上げられた構造であるため、問題が少ない。

いくら熟練したシニア開発者でも、デザインパターンを誤って適用する場合がよくある。それも、よく知っているにもかかわらずだ。だからジュニアだけでなくシニアであっても、常に絶えず勉強し、理解しようと努力しなければならない。さらには新しいパターンを研究してみるのも良い。

まずデザインパターンを「勉強」する前に、なぜ誰でも実装できる解決策などが、長い期間練り上げられてパターンという名前で定着したのかを知る必要がある。その理由は、デザインパターンは単純な方法論ではないからだ。 これを知るために、我々は SOLID 原則を先に知る必要がある。その後、すべてのデザインパターンは結局、様々な実装方法を SOLID原則を守りながら実装 するために作られたということを悟り、さらにはこの原則を常に考える習慣をつけなければならない。デザインパターンを適用したとしても、SOLID原則が守られていなければ、誤って適用されたパターンだと見なすことができる。

とにかく、目次は以下の通りだ。

1. SOLID
2. 生成(Creational)デザインパターン
   1. Singleton
   2. Factory
   3. Abstract Factory
   4. Builder
   5. Prototype
3. 構造(Structural)デザインパターン
   1. Adapter
   2. Bridge
   3. Composite
   4. Decorator
   5. Facade
   6. Flyweight
   7. Proxy
4. 振る舞い(Behavioral)デザインパターン
   1. Chain of Responsibility
   2. Command
   3. Interpreter
   4. Iterator
   5. Mediator
   6. Memento
   7. Observer
   8. State
   9. Strategy
   10. Template
   11. Visitor
5. アーキテクチャパターン
   1. MVC
   2. MVP
   3. MVVM
   4. MVI

なので次の記事では、SOLID 原則について一つ一つ掘り下げてみようと思う。

おすすめサイト

• Refactoring Guru - Design patterns