パート2：機能を維持する原則
構成がどのように有害で、多くのコードを書くのが悪いのかを説明します。 他の部品はここにあります 。
多くのプログラミング言語は、データ構造の記述的（宣言的）アプローチと、データ操作を記述するための命令的アプローチの両方を組み合わせています。
例はC / C ++で、ヘッダーファイル（* .h）が宣言的にデータ構造、関数とメソッドを記述し、プログラムファイル（* .c / *。Pp / *。Cpp）が命令型言語でアクションを記述します。データ。 別の例はPHPです。PHPは、視覚化のためのデータ構造を記述するHTML部分（すべてML言語は宣言型）と、構造をデータで満たすアクションを記述するように設計されたPHP部分に分かれています。
一般に、データ変換機能はチューリングマシン上のプログラムに縮小できることを覚えておくことが重要です。 この言語がどの言語でどのパラダイムで作成されたかは関係ありません。 したがって、ロモノソフ-ルボアジェの物質の保存の法則との類推によって、機能の保存の法則を導入することができます。
プログラムの機能の量は、ソースとデータフローの違いによってのみ決定され、プログラム内の変換の数は機能の量に影響しません。
実際、この法則は、エントロピー増加の尺度に関する熱力学の第3法則の取り決めの1つです。 次のように再定式化できます。
機能の量が増えると、コードの量も増えます。
この法則は、プログラミングの理論を理解するための基本の1つです。 コードが増えても機能が増えるわけではないことが明確になります。 しかし、より多くの機能が無料になることは決してありません。たとえば、コードの行などの移行ルールの説明で、機能の増加に対して支払う必要があります。
構成プログラミングの定理
この法律の重要な結果は、設定プログラミングの定理です。 実際、設定ファイルを変更すると、プログラムに入ってコードを変更する必要がないという前提に基づいて、設定ファイルは通常プログラムから取り出されます。
構成ファイルは、本質的に情報のソースであるだけでなく、この情報が格納されているデータ構造の宣言的な記述であることも忘れられがちです。 実際、設定ファイルは宣言型言語のプログラムです。
したがって、設定ファイルを追加すると、プログラマは少なくともプログラムに貢献します
a）新しいデータソース
b）設定ファイルのインタープリターが書き込みます
つまり、プログラマーはプログラムに新しい機能を追加し（別の外部データソースを追加するため、プログラムはこのソースからのデータ変換をサポートする必要があるため）、この機能の一部を親プログラムとは異なる親言語で記述しますYaP（実際には、構成の言語）。
機能の量に関する法律によれば、プログラマは、機能のプログラミングに関するユーザーの懸念を完全に取り除くような方法で設定を作成することはできません。機能の一部は常に設定言語で記述されます。
プログラムが構成を必要とするほど、これらの構成のユーザーはプログラムを行う必要があります。 構成が同時に異なる充填形式（プロパティファイル、XML、GUIフォームなど）を持っている場合、ユーザーはさらに、これらの構成と同じ数の新しいPLを学習する必要があります。 したがって、これはユーザーに幸福を与えません。
プログラムをより機能的にし、さまざまな状況に柔軟に対応し、システムの外部で設定をしようとすると、プログラマーは単に母プログラムのエントロピーを増加させ、新しい宣言型言語ツールを作成し、ユーザーにこれらの宣言型言語コードでプログラムすることを強制します。
機能を実装せずに、設定で有効にすることを可能にすることで、プログラマはこの機能をプログラムする義務を自分からプログラムのユーザーに移します。
シンプルなフレームワーク定理
構成プログラミングの定理の結果の1つは、「柔軟でカスタマイズ可能なフレームワーク」の問題です。 実際、フレームワークの本質はAPIの提供です。 APIは、実際には、このフレームワークを使用するためのルールを記述する宣言型言語でもあります。 より多くのAPIが公開されると、このAPIで使用できるパラメーターが増え、この言語はより豊かになり、学習するのが難しくなり、したがって使用することが難しくなります。
最も論理的で理解しやすいフレームワークは、最小限のAPIとその背後にある最大限の機能を提供するフレームワークです。
論理的で理解可能なフレームワークとは何ですか？ フレームワークを使用すると、同じことをいくつかの異なる方法で実行できる場合、これは、このフレームワークの宣言型API言語が冗長であることを意味します。 単純なフレームワークは、APIの冗長性が最小限のフレームワークです。
バビロニア語混合定理
情報の各ソース、したがって各タイプの情報には、このタイプの情報を内部のネイティブ（ネイティブ）表現に変換するコードが必要です。 たとえば、構成は情報の表示の構造を規定し、APIは呼び出しのルールを規定します。 逆に、各API、各構成が新しい情報ソースを生成することも事実です。これらの情報は、呼び出し元がネイティブ形式に変換する必要もあります。
したがって、プログラムで使用される言語と言語のペアが多いほど、使用されるデータ構造が多くなり、変換を含むプログラムが増えます。 この場合、変換の数は、PLプログラムに基づいたデータ構造を使用して情報がプログラムに入力された場合よりも多くなります。
実際、1つの追加の構成または追加のプログラミング言語を使用すると、プログラムの母国語で記述された別のデータソースまたは別のデータ構造を追加する場合の2倍のコードがプログラムに追加されます。
プロジェクトで使用される言語が異なるほど（異なる形式の構成や異なるAPIを含む）、同じ機能を維持しながらプログラムにより多くのコードが表示されます。
実際、バビロニア語の混合言語の定理は次のとおりです。
フレームワーク、構成、またはPLを追加してデータ解析を促進すると、データ解析が複雑になります。
新しいバスケットの機能を使用している人たちが直接これに直面しました-いくつかのタイプの構成で、いくつかのタイプのAPIを使用して、記述的およびエグゼクティブパラダイムの素晴らしいミックスが提示されています。