読んでクリーンなアーキテクチャもちろんのを、あなたは作家が頻繁に言及したでしょうrecompile redeploy、これらの用語は、それは、Java、C ++、C＃など、関連すると思われる静的型付け言語に関連しています。私は頻繁に使用するPython言語で、これらの概念は存在しません。原則の多様になりますの疑いが読んだときに、「クリーンなアーキテクチャ」動的言語を入力するかどうか、このような固体として、言及されている-同じことが適用されます- Pythonのような？
SOLIDは、OOPの基本理念である、より多くのガイダンスは、デザインパターン、GOF古典の多様であるべきデザインパターン：再利用可能なオブジェクト-の要素指向ソフトウェアは、 例えば、C ++にもあり、これらの古典的なデザインパターンの多くが動的に適していますかPythonなどの言語はありますか？認知間違った場所がある場合は、この記事で、これらの問題の文書の浅い思考も、お気軽にどうぞ。
この記事のアドレス：https://www.cnblogs.com/xybaby/p/11767100.html
固体
固体を次の5つの原則からなる、モジュール（モジュール）設計の指針であります
- SRP（シングル責任の原則）：単一責任の原則は、モジュールは、変更のための唯一の理由の1つです
- OCP（オープン/クローズの原則）：オープン - クローズ原則、オープン拡張、修正が閉じ
- LSP（リスコフの置換原則）：リヒターまた原則は、彼らにサブタイプの基本型を交換することができなければなりません
- ISP（インタフェースの分離の原則）：インタフェース棲み分け原理、あなたが実際に使用されているに依存しなければなりません
- DIP（依存性逆転原理）：依存関係逆転の原則、（基礎となる実装を知らなくてもトップを）達成するためのインタフェースに頼るのではなく、
ISP
、インターフェイス分離の原則、「クリーンなアーキテクチャは、」これは言語依存の原則の認識ISPの最初の外観です
この事実は、ISPは、言語の問題ではなく、アーキテクチャの問題であるという結論にあなたを導くことができました。
次のようになぜ、ISPは主に、不必要な再コンパイルおよび再デプロイ「ファット・インタフェース」の原因を解決するために：
Use1するop1ユーザー2ユーザー3につながる、OPSの変更に結果を使用するには、再コンパイルする必要があります。動的言語では、既存の再コンパイルするような問題ではありません。
RubyやPythonのような動的型付け言語では、このような宣言は、ソースコードには存在しません。代わりに、彼らは、実行時に推論されています。こうして再コンパイルおよび再配置を強制するソースコードの依存関係が存在しません
浸漬
DIP（依存性逆転原理）DIPに依存し、実際にはSOLID、OCPのコアです。これは、DIPはの「クリーンアーキテクチャ」の中核である、と言うことができます。
「クリーン・アーキテクチャ」は、2つの部分から構成されます。
- よく単離された成分
- 依存関係のルール
「依存関係のルールは、」それは何ですか？ハイレベルのポリシーに依存する低レベルの詳細をしてみましょう。例えば、ビジネス・ロジック（ビジネスルール）データ記憶装置（データベース）と比較して、より高いレベルに、データベースのビジネスロジックを使用することが論理的であるが、しかし保守のため、スケーラビリティ、お奨めデータベースは、ビジネスアーキテクチャに依存してもらいます図に示すように、ルール。
チャートからわかるように、この目的を達成するために、静的言語で、私たちは、双方がこのインターフェイスに依存していると呼ばれるインターフェースを宣言します。上図のようにdatabase interface、ビジネス・ルールとデータベースがこのインターフェースに頼らなければならないせ、データベース依存の高レベルのビジネスルールを可能にするために低いレベルを達成する一つの成分で、このデータベース・インターフェース、ビジネスルール、。
（Java（登録商標）、C ++など）静的型付け言語では、実際には、この機能を実行することが可能となり、実行時のポリモーフィズムの使用です - 時間ではなく、コンパイル時に - ソフトウェアの動作を変更するために、当然のことながら、この目的を達成するためには、宣言する必要があります仮想基本クラスまたはインタフェース（Javaインターフェイス）。
そして、Pythonで、もともと価値を追求する時間を実行するだけでなく、事前申告・インタフェースなしので、種類をダッキングためか、継承されたインタフェースを強要
依存反転が宣言またはインタフェースの継承のいずれかを必要としないので、これらの言語（動的型付け言語）に依存構造は非常に単純です。
静的型付け言語の動的型付けする言語から、実際には、多くのことを省略します
- 仮想関数は、テンプレートメソッドモードとして、省略されています
- そのようなDIP、戦略モードとして省略仮想基本クラス、インタフェース、
Pythonの依存性と依存性逆転
Pythonでは、どのように依存して数、どのように依存逆さまのカウントダウン？
'''my.py'''
import other
class My(object):
def f(self):
other.act()コードのこの作品importメイクモジュールは、myモジュールに依存しother、
'''my.py'''
class My(object):
def __init__(self, actor):
self._actor = actor
def f(self):
self._actor.act()だからここに、私や他の依存関係は？いいえ、彼らは他には存在していないされています。動的な型プラスダッキング型に、必要明示的なインターフェイスの定義は、単にすることができ、関連する契約（契約）に従うません。そして、この契約、コードに縛ら強制する方法は、発信者ニーズへのインタフェースの種類、呼び出し側は、文書（またはユニットテスト）で記述することができる行動の種類を持っている必要があります。
契約の発現のために、上記のコードでは、ドキュメント文字列を追加する必要があります
'''my.py'''
class My(object):
def __init__(self, actor):
'''Param: actor，该对象需要具备接收0个参数的act方法
'''
self._actor = actor
def f(self):
self._actor.act()Pythonの広範な使用などの同様のプロトコル、context management、iterator protocol。それは便利ですが、少なくともドキュメンテーション文字列のフライを持っている必要があるためにも、プログラマのための高い期待を持っていますが。あなたが使用して考えることができる制約課す必要がある場合は、ABCのを。
デザインパターン
まず、この記事のデザインパターンに記載されている文は、一般的に指し再利用可能なオブジェクト-の要素：パターン設計指向ソフトウェア本書で説明する古典的なデザインパターンを。
ずっと前++「静的言語の欠陥を補うために++デザインパターン」言って、見て、あなたはそれを受け入れるだろう、と私は謙虚に、これが真実であると考えて考えていませんでした。最近、本当にこの問題について考え、私たちは、この引数はバイアスされ、不完全見つけました。
まず、質問を投げる：デザインパターンは言語、それに関連している（言語固有の）？他のプログラミング言語は必要ありませんが、モードを設計するためのプログラミング言語のいくつかのタイプ？またはその必要が異なるプログラミング言語のデザインパターンは同じではありませんか？
ここではデザインパターンとは何か、ソフトウェア設計における問題の特定のクラスにシンプルかつエレガントなソリューションとして記載されている「デザインパターン」。
オブジェクト指向のソフトウェア設計における特定の問題にシンプルかつエレガントな解決策を説明します
換言すれば、特定のデザインパターンは、特定の問題のルーチン又は方法論を解決します。ルーチンは、理論的または実証済みの、効果的な方法と手順の後、質問への応答です。方法論は、問題を解決することはできません、あなたはソリューション（最適解のない大規模な確率）を得るために試行錯誤の多くを試してみる必要があるかもしれません、解決プロセスは時間がかかり、非効率的です。そこで我々は、方法論（モデル）が問題解決のプロセスを加速するために、言うことができます。
例えば、プログラマーが毎日やることがたくさんある：ミーティング、自分自身を充電するために、バグを処理するコードを記述します。それをアレンジする方法？この質問は自身が傷ついたとボロボロのために考える必要があるかもしれませんが、すでに成熟した方法論がある - アイゼンハワーマトリックス - 利用ああのために利用可能に。
私たちはしばしばルーチン、方法論は巨人の肩で、巨人の肩の上に立って、言います。
同じことが、真のデザインパターンです。
デザインパターンと動的言語
1994年に書かれた「デザインパターン」本は、著者がこの番号を書き込むの目標は言及これらの実績のある経験の記録。先に述べたように、デザインパターンは、問題のクラスのためのソリューションです、そしてデザインパターンを提示し、何かが常に（を含むがこれらに限定されない）は、以下の内容が含まれます。
- 解決すべき問題は何ですか
- 解決策は、次のようになります
- ソリューションの欠陥やアプリケーションのシナリオ
- 詳細な手順ソリューション
- 同じ問題のために、他のソリューション、彼らの長所と短所はありません
もちろん、最初にすべての名前適切にこのモデルを取らなければならない、命名の重要性を疑問視することはできません。少なくともかかわらず、通信がピアツーピア、またはコードを介しているかどうかの、同じ問題にプログラマとの間の通信の発現を確実にします。名前（用語、定義は）コミュニケーションのコストを削減します。
1996年に、2年書かれた「デザインパターン」の後、ピーター・ノーヴィグは、「共有んダイナミックプログラミングでのデザインパターンを」、による制限の少ない言語レベルまで、動的言語、GOFのデザインパターンのほとんどがあることを指摘Lispのか、ディランに単純な実装を持っていない、と注意を払うためにいくつかのも、単に必要
各パターンの少なくともいくつかの用途のために23個のパターン16は、C ++よりもLispの又はディランで定性的に単純な実装を持っている
23個のパターン16は、目に見えないまたは簡単のいずれかであります
だから何パターンは、それの「単純」である、「不可視」になりますか？
3つのカテゴリに分類デザインパターンの話では「デザインパターン」
- 生成に関する：オブジェクトのインスタンス化の方法と手段
- 構造：クラスまたはオブジェクトの相互組成（ファサードDPが構造的です）
- 行動：クラスやオブジェクトがinteractandそれらの間で責任を配布する方法
そのため動的型付け言語では、カテゴリ（クラス、タイプ）とメソッド（関数）はファーストクラスの市民なので、Creational patternsPythonなどの動的型付け言語では、それは「見えなく」なりました。
動的な型、種類をダッキングに番号Creational patterns「ビジター」など「オブザーバー」としては、「単純」になるために。疎結合の設計原理を代表して、デザインのすべてのレベルであり、公開-簡単には、このようにオブザーバーモードとして存在するモード、またはサブスクライブがあることは意味がないという意味ではありませんことを強調しなければなりません必要に応じて。
このデザインパターンについて高い原則、アイデアを反映して、私たちは考え、通信を支援するためにモデルを使用する必要がありますが、定型コード、特定の言語を貼らないでください。StackExchange非常に適切で、この並列処理文：
- I might say that I have a visitor pattern, but in any language with first class functions it will be just a function taking a function. Instead of factory class I usually have just a factory function.
- I might say I have an interface, but then it's just a couple of methods marked with comments, because there wouldn't be any other implementation (of course in python an interface is always just comments, because it's duck-typed).
- I still speak of the code as using the pattern, because it's a useful way to think about it, but don't actually type in all the stuff until I really need it.だから、戻って質問に、デザインパターンは言語に依存していること（言語固有の）？
私の答えは、設計モデルの一部も変更することができる特定のパターンに特有の、言語に依存しない、デザインパターンの一部は、言語に関連している、です。
特定の問題に関連する - なぜ、厳格な、我々は唯一の問題は、パターンを設計することが関係していると言うことができます。コアは、どのような状況下での質問は確かに問題であるということです。また、開発して、古い問題を死ぬだろう、新たな問題が発生します。
プログラミング言語に固有の、あなたが問題を考えるべきである言語依存ではありません。例えば、C ++などの静的型付け言語では、オブジェクトの型を持っている、タイプは、マルチステートを実行するために、仮想基底クラスを持っている持っているだけでなく、さまざまなを必要とOCPを行い、その動作を決定します生成に関するパターン。しかし、動的型付け言語では、これはもはや問題ではありませんので、あなたは、もはや対応するモードを持っています。