design-patterns - SOLID 原則を実装するためのパターン

Question

私は SOLID デザイン原則のプレゼンテーションを行っており、単一責任原則とオープンクローズ原則をデザイン パターンに結びつけようとしています。

現在、私は持っています

• SRP:プロキシ、ファサード
• OCP:戦略、コマンド

含める必要がある他の基本的なパターンはありますか?

Answer 1

SOLID の原則は、優れた OO 言語とフレームワークの何よりも重要な属性です。それらは簡単に設計パターンに変換されません。むしろ、それらはデザイン パターンの善悪に影響を与えます。

一般に、SOLID の原則はすべて、各設計パターンのどこかに現れます。すべての SOLID 原則が表示されない場合は、設計パターンを改善する方法があります。

単一の責任は、実際にはカプセル化に加えて、継承とポリモーフィズムのいくつかの側面です。単一の責任は、問題を協力するオブジェクトに分解し、それらのオブジェクトのクラスを定義する方法の基本原則または信条です。すべての設計パターンでこれを説明する必要があります。

同様に、Open/Closed は言語機能であり、通常は継承によって実装されます。しかし、それはモンキーパッチを介して行うことができます。すべての設計パターンでこれを説明する必要があります。

Liskov 置換も、通常は言語機能です。多くの場合、適切に設計されたポリモーフィック クラスでこれを実装します。ダックタイピングがこの原則を破っていると主張する人もいれば、ダックタイピングがそれを明らかにしていると主張する人もいます。Liskov Substitution に依存する設計パターンは数多くあります。ポリモーフィズムのあるものはすべてリスコフ置換を示します。

インターフェイスの分離は、言語機能の 1 つです。Javaにはそれがあります。Python は -- ほとんどのアカウントで -- これを行いません。ただし、多くの Python プロジェクトは、スーパークラスと単体テストを使用してインターフェイス定義を形式化しようとしています。

依存関係の逆転 (抽象化に依存) は、多くの場合、言語機能です。これを主張する設計パターンは多くありません。しかし、具象クラス間で Liskov Substitution を使用できるように、Java Collections ライブラリの抽象化を使用することを好みます。

Answer 2

私は同じプレゼンテーションを行い、原則をどのように適用するかを示すためにいくつかの設計パターンを選びました。

LSP の場合、GOF の 2 つの設計パターンを除くすべてが置換を使用していることに注意しました。