KISS-他のすべての設計原則を含む設計原則

KISSの設計原理の本質を簡単かつ同時に詳細に説明しようと思います。 KISSは、他のほとんどすべての設計原則を含む非常に一般的で抽象的な設計原則です。 設計原則では、「適切な」コードを記述する方法を説明しています。 しかし、良いコードとはどういう意味ですか？ これは、可能な限り高速に実行されるコードであると考える人もいれば、可能な限り多くの設計パターンが関係するコードであると考える人もいます。しかし、正しい答えは表面にあります。 コードは純粋な情報です。 そして、情報の価値に関する主な基準は、1）信頼性2）アクセシビリティ3）理解可能性です。 信頼性とアクセシビリティが重要である理由は明らかです。 コードからは、エラーが発生した場合や、アプリケーションがインストールされているサーバーが「嘘をつく」場合は役に立ちません。 コードの理解性が重要なのはなぜですか？ 理解可能なコードでは、エラーの検索が簡単になり、エラーの変更、修正、および保守が簡単になります。 そのため、プログラマビリティーが理解すべき主な価値は理解可能性です。 ただし、1つの問題があります。 事実は、理解可能性は純粋に主観的なものであることです。 もっと客観的な理解の基準が必要です。 そして、この基準はシンプルです。 実際、単純なアプリケーションは複雑なアプリケーションよりも理解しやすいものです。 ただし、シンプルさを実現することは困難です。 Peter Goodwinが彼の著書「The Craft of a Programmer」に書いていることは次のとおりです。

プロジェクトが単純な場合、理解するのは簡単です...単純なプロジェクトの開発はそれほど簡単ではありません。 時間がかかります。 複雑なプログラムの場合、最終決定は膨大な量の情報を分析することによって得られます。 コードが適切に設計されていれば、他の方法では実現できなかったように見えますが、集中的なメンタルワーク（および大量のリファクタリング）の結果としてその単純さが達成された可能性があります。 シンプルなものを作るのは難しいです。 コードの構造が明らかな場合は、簡単だとは思わないでください。

そのため、KISSの設計原則（シンプルでわかりやすいものにする）は、シンプルなコードが最も理解しやすいため、コードのシンプルさが最も重要であると宣言しています。

ほとんどすべての設計原則は、コードの明瞭度を達成することを目的としています。 設計原則に違反することにより、コードの理解度が低下します。 理解できないコードは、理解や修正が難しいため、コードが複雑であると自動的に感じさせます。 これらの原則のいずれかに違反した場合、KISSの原則にも違反します。 したがって、KISSには他のほとんどすべての設計原則が含まれていると言えます。

設計パターンは、いくつかの問題に対して最も成功し、単純で、明確な解決策を説明します。 このパターンが解決する問題がないデザインパターンを使用すると、KISSに違反し、コードに不要な複雑さが生じます。 パターンに対応する問題がある場所でデザインパターンを使用しない場合は、KISSが再度破損し、コードが複雑になります。



私の意見では、KISSの原則は 、デザインの基本原則を知らない、または理解していない初心者のデザイナーにのみ有用です 。 KISSは、設計原則とパターンの誤用から保護します。 原則とパターンはコードの理解度を高めるように設計されているため、それらを適切に使用してもコードの理解度が低下することはありません。 ただし、設計原則を誤解している場合（たとえば、「不要なエンティティを作成しない」を「できる限り少ないエンティティを作成する」と解釈する）、または1つの原則を遵守し、他の12の原則に違反する場合、KISSは信頼できるエアバッグになります。 それ以外の場合、KISSはほとんど役に立ちません。 彼はあまりにも一般的かつ抽象的です。 残りの原則はより具体的であり、コードのわかりやすさと単純さを実現するためのより明確な方法が含まれています。



「単純性」などの概念に関する人々の考え方はさまざまである可​​能性があるため、 KISS-aに関する次の誤解が広まっています。

誤解1.単純なコードが最も簡単に記述できる種類のコードであると想定する場合、KISSの原則は、設計を考えずに頭に浮かぶ最初のものを書くことを奨励していると解釈できます。

誤解2.単純なコードが、書くためにできるだけ知識を必要としないようなコードであると仮定する場合、KISSの原則はデザインパターンを使用しないことを推奨していると解釈できます。



この場合、単純さは複雑ではなく、人工的でなく、最も自然で、難しくなく、理解しやすいものとして理解されるべきです。

C＃の例

タスク：図形を横断するときは、その交差部分をシェーディングする必要があります。

それで、異なる組み合わせのための普遍的なhatch化アルゴリズムを開発する方法

形状（長方形-長方形、長方形-多角形、

polygon-polygon、ellipse-polygon、ellipse-ellipse）かなり

難しく、ほとんどの場合、あまり効果的ではありません。

オプションは独自のアルゴリズムです。



最初に思い浮かぶのは次のようなものです：







ただし、このコードは、単純さの定義からの2つのポイント、つまり最も自然で理解しやすいものと矛盾しています。 人工的なクラスIntersectionFinderがあるため、コードは自然ではありません。 コードに慣れていない人は、交差点計算関数が実装されているかどうか、およびその使用方法を理解するために、IShapeが使用されているすべての場所を調べる必要があるため、コードを理解するために簡単にアクセスできません。 数万（または数百）のコード行を持つプロジェクトでは、これは簡単な作業ではないかもしれません。 IntersectionFinderクラスでの作業が難しくなるもう1つの不快な瞬間があります。FindIntersectionという名前の関数の数は、数字の数から算術級数の形で増加します。その結果、IntersectionFinderクラスは、時間の職業。 したがって、FindIntersectionをIShapeに転送します。







さて、今ではコードに不慣れなプログラマーは、2つの図の共通部分を作成するためにプロジェクトを回避する方法を探す必要はありません。 不要なエンティティ「交差電卓」が消えました。 コードがより自然になり、理解しやすくなりました。つまり、よりシンプルになりました。 これで、新しいタイプの図を作成するときに、以前に作成したクラスを変更する必要がなくなりました。つまり、新しいタイプの図の追加も簡素化されました。 特定の交差検索アルゴリズムを見つけるのは簡単です。同じ名前の多くのメソッドの中から巨大なクラスで検索する必要がなくなったためです。



しかし、交差点を計算する特定の関数を呼び出す必要があるかどうかを決定する方法には、人為性がないわけではないことがわかりました。 より自然なアプローチは、次のとおりです。FindIntersectionと呼ばれる関数を呼び出し、その引数の型は2番目の図の型と一致します。







ご覧のように、パブリックIShape FindIntersection（IShapeシェイプ）メソッドは、図の各具体的なクラスから消えており、コードの合計行数が削減されています。 新しいタイプの形状の追加がさらに簡単になりました。 FindIntersection（Shape shape）メソッドは現在、基本クラスにあり、よりシンプルで自然に見えます（ 宣言的 ）。 新しいMethodFinderクラスが追加されましたが、プログラマはその内部構造を知る必要はありません。 明確なインターフェースを持ち、サブジェクト領域の概念を実装していません（つまり、変更の理由はほとんどないことを意味します）。したがって、追加されたコードの複雑さは実際には増加しませんでした。

ここでは、リフレクションは遅いものであると考えられ、加速のために、たとえば、ExpressionTreeを使用して動的に形成されたデリゲートをキャッシュできますが、KISSはできるだけ単純なコードを記述することをお勧めします。そのため、FindIntersectionメソッドが高速になるまでこの考えは控えてください（形状）は、実際にはプログラムのボトルネックにはならず、ユーザーに問題をもたらします。 しかし、延期してはならないのは、リフレクションを通じてShapeクラスのすべての子孫を認識し、プログラマーがすべての図形のペアに対して交差検索アルゴリズムを実装することを忘れていないことを検証する単体テストの作成です。







最初の例と3番目の例を見ると、3番目の例のほうが簡単なことは明らかではないかもしれません。 しかし、数字のタイプが3ではなく30であると想像してみましょう。その後、数字比較関数の数は465（算術的進行の合計（1 + 30）* 30 \ 2）です。 最初のケースでは、必要な関数を選択するためのメカニズムが465 ifs（または、代わりにメソッドへの465ポインタを持つコンテナの背後にありますが、あまり良くはありません）と、このifの山の中で、コードに不慣れなプログラマーが隠れます特定のシステム。 一方、3番目のケースでは、アプローチは宣言的であり、数字の種類の数に依存しません。 この例は、プログラマーの大部分が3番目の例が悪い決定であると考えるかもしれないという点で優れています。なぜなら、リフレクションを使用してプライベート変数（プログラマーの一種のタブー）にアクセスするからです。そのような目的のための反省は悪いですが、彼らはなぜそれが悪いのか説明できません。 この心理現象は固定値と呼ばれます。











この例は、KISSを使用してコードを簡素化しようとすると、特定の原則やタブーの誤った理解が、開発者の意図を完全に反映する宣言コードの代わりに「松葉杖」を使用するように指示した場合でも、問題のより良い解決策に到達する方法を示しています。



少し歴史。

KISSの原則は、航空機産業に由来し、歴史的に「単純に愚かにしておく」と訳されており、「単純に愚かにする」の略です。 航空機製造の歴史では、機体の重さが計算されたものよりも大きくなり、飛行機が単に離陸できなかったため、飛行機の戦闘力を高めるために飛行機に余分な鎧のプレートを釘付けにした労働者が多すぎる場合が知られています。 さらに、多くの労働者のスキルは低かった。 このような条件下では、酔っぱらった未熟な労働者が、たとえたとえ彼が望んでいたとしても、誤って組み立てることができないという航空機の設計は、特別な価値がありました。 その当時の設計決定の反響の1つは、混同してコンピュータのソケットに間違ったプラグを差し込めないことでした。 ただし、エアエンジニアの作業の結果が図面であり、製品が作成される場合、プログラマーの場合、製品は図面そのものです（具象的に）。 プログラマーの場合、彼は、酔った未熟なプログラマーが、変更されたビジネス要件に応じて変更を加えることができるようにコードを書く必要があります（つまり、図面を変更し、飛行機を組み立てません）。 航空機業界とプログラミングの仕様の違いにより、航空機業界に適した「シンプルに保つ」デコードは、プログラマーの原則の本質を反映しなくなりました。 多くの怠programmerなプログラマーは、「イディオムを簡単にする」を「デザインを気にしない」と解釈します（たとえば、この記事のKISS原則の説明をこの説明と比較してください）。 幸いなことに、KISSには他にもいくつかの復号化機能がありますが 、そのうちの1つは、プログラミングにおけるKISSの本質を最もよく反映しています。 単純明快とは、単純で、正直で、率直で、率直なものです。 したがって、「シンプルでわかりやすいものにする」は、「シンプルでわかりやすいものにする」と自由に翻訳でき、宣言性を実現するにはデザインが必要です。



この例では、 Hokumに感謝します。Hokumは 、この例の最初のアイデアを提供してくれました。