（更新：写真をより中立的なものに置き換えました）
同僚が会話の中で「構成よりも規約」の原則に言及しましたが、それは気のせいだと思います。恐らくそれはクールだと思います。勉強し、記事を読む必要があります。
すべての説明が「必要に応じて再定義できるデフォルトを使用する」という1つのフレーズに配置されていることに驚きました。
そして、実際にはそこには複雑なものはありませんが、スマートな顔としわのある額で発音される多くの原則が概説されていると思いました。 それらの多くは、1つのフレーズで説明できます。 まあ、テキストのパラグラフか実用的な例かもしれません。 指で、要するに。 一般的に、誰かが彼自身が長い間勉強したことをすぐに説明することがよくあります。 そして、いくつかの詳細は後で成長し、主なことは「キー」を取得することです。
最後に、私はそのようなタブレットを作ろうとしました。 ロシア語-中国語の一種のフレーズブックと言えます：
| 価値 | 翻訳 |
|---|
キッス
「短くシンプルに保つ」、
「シンプルに、馬鹿にしよう！」など | 正当な理由なしにコードを複雑にしないでください。 |
| カプセル化 | オブジェクトが何の中にあるかを知る必要はありません。ただパブリックメソッドを使用します。 したがって、複雑なシステムを単純化して理解し、オブジェクト同士のつながりを減らします |
| 構成より規約 | すべてを記述する構成の代わりに、デフォルトを使用することをお勧めします。必要に応じて、構成で再定義できます。 |
バーバラ・リスコフの代替原理
元の表現：「 ... q（x）をあるタイプTのオブジェクトxに対してtrueとします。その後、q（y）はタイプSのオブジェクトyにもtrueでなければなりません。SはタイプTのサブタイプです... ） | 下位クラスの動作は、親クラスで指定された動作と矛盾してはなりません。
クラスDogのオブジェクトを、動物Animalのオブジェクトが期待される場所に簡単に置き換えることができるように |
| 単独責任の原則 | クラスは1つのことを行う必要があります。 |
インターフェース分離の原理
「... 顧客は、使用しない方法に依存すべきではありません ...」 | コンストラクターまたはメソッドの引数では、クラスが小さな特定のオブジェクトまたは愚かな整数のみを必要とする場合、多くの不必要な詳細を持つオブジェクトを期待しないでください。
また、依存関係のコンテナをすべてのクラスに押し込む必要はありません。
|
| 高い凝集力 | クラスは1つのことを行う必要があります:)。 一部のメソッドが、他のメソッドとは別に、独自のデータの一部を使用して別々に使用されている場合は、凝集度が高くありません。 クラスを部分に分割するか、メソッドの一部を別の場所に移動する価値があるかもしれません。 |
| 低結合 | クラスは他のクラス、特にその内容にできる限り拘束しないでください。 犬の足を制御しないでください、犬を制御します |
依存関係の逆転の原則
「...最上位モジュールは下位モジュールに依存するべきではありません。両方のタイプのモジュールは抽象化に依存する必要があります。抽象化は詳細に依存するべきではありません。詳細は抽象化に依存する必要があります...」 | クラスはできるだけ他のクラスに結び付けてはいけません:)
コードの柔軟性のために、コンストラクター/メソッドの引数は、具体的なクラスではなく、インターフェイスまたは抽象クラスを作成する必要があります。 |
開放性/近接性の原理
「...ソフトウェアエンティティ（クラス、モジュール、関数など）は展開のために開かれている必要がありますが、変更のために閉じられている必要があります...」 | 新しい機能は、すべてを行う既存のクラスに新しいifブランチを追加するのではなく、新しいクラスを追加して追加する必要があります。
|
ヤグニ
「あなたはそれを必要としません」、「あなたはそれを必要としません」 | 要求されていないことをする必要はありません。 「将来必要になるかもしれない」アプローチは、コードとサポートを非常に複雑にします |
補足、修正、または議論したい場合-通常どおり、コメントを記入してください