懸念の分離について書いたとき、ダイクストラはコードのモジュール化を意図していましたか？

まず、私は1974年の「科学的思考の役割について」の抜粋エズガーW.ダイクストラの論文を読みました。

私にあなたに説明しようと思います、私の好みに何がすべてのインテリジェントな思考に特徴的です。それは、自分の一貫性を保つために、自分の主題の側面を分離して詳細に研究することをいとわないことです。常に、側面の1つだけで自分を占有していることを知っています。私たちはプログラムが正しい必要があることを知っており、その観点からのみそれを学ぶことができます。また、効率的である必要があることもわかっており、いわば、別の日にその効率を調査することができます。別の気分では、プログラムが望ましいかどうか、またそうである場合、なぜプログラムが望ましいかを自問することがあります。しかし、これらのさまざまな側面に同時に取り組むことによって何も得られません-逆に！-。それは私が時々「懸念の分離」と呼んだものであり、それは完全に可能ではないにしても、私の知る限り、思考を効果的に順序付けるために利用できる唯一の手法です。これは、「ある側面に注目する」という意味です。他の側面を無視することを意味するのではなく、この側面の観点から見れば、他の側面は無関係であることを正当化するだけです。それは1つと複数のトラックを同時に気にしています。

私は、コードをモジュール化することについて、現代の懸念の分離が語られているのを見ています。しかし、上記の引用を読んで、私はこれをあなたの心を一度に1つの特定のタスクに集中させ、他の側面に焦点を合わせないものとして理解します。これは、必ずしもコードをモジュール化されたチャンクに分離する必要があることを意味するわけではありません。

つまり、1つのファイルに、ビュー、リポジトリ、コントローラー、イベント処理、ファクトリーなどの概念がすべて1つのファイルにあるというコードが目の前にあるとします。

簡単な例として、データアクセスと表示（出力）を行うコードを次に示します。

$sql = "SELECT * FROM product WHERE id = " . db_input($id);
$row = db_fetch_array(db_query($sql)); 
<option value="<?=$row['id']?>"<?= $row['ver'] == $row['ver'] ? '  selected="selected"' : '' ?>>Version <?=$row['ver']?></option>

モダンなオブジェクト指向を使用して、リポジトリパターンを使用して独自のファイルにデータアクセスを配置し、ビューコードを独自のファイルテンプレートに入れ、それらをまとめてコントローラー（またはアクションまたはリクエストハンドラー）を介して通信することができます。ファクトリーを追加して、さまざまな依存関係を作成して接続します。そして、それらのファクトリーを定義する構成ファイルを持つことができます。確かに、それは単一ファイルのすべてから一歩離れています。

懸念の分離に関する私の質問は次のようなものです。ダイクストラの引用を読んで、おそらく彼が懸念の分離を必ずしも「コードのモジュール化（ファイルまたは独自の関数/メソッド/その他への）分離」であるとは限らないという考えを得ました。また、コードで物理的に分離されているかどうかに関係なく、他の重要であるが現時点では検討されていない側面に集中することなく、プログラムの側面に集中することを意味しました。

では、なぜ、物理的なモジュラーコードの分離と設計パターンに負担をかけているのでしょうか。コードがどのように構造化されているかに関係なく、アスペクトに専念するだけでは十分ではありませんか？

私は最も恐ろしいスパゲッティコードを書くことについて話しているのではなく、その側面のみを検討しているので、それはおそらく負担になります。しかし、結局のところ、私が目指しているのは、物理的なコード分離を実行する理由であり、側面に精神的に集中する必要がないのに、なぜコードを個別のファイルまたはチャンク（メソッド）に分割するのか、です。

懸念の分離は、肉体的ではなく精神的な運動のままである必要がありますか？
言い換えれば、プログラミングの精神的側面（焦点を当てる）と物理的側面（紙面上のコード）の間に断絶があるべきでしょうか？

ダイクストラはどのように考えるかについて明確な声明を出している。プログラム（およびプロセス）のモジュール化-そしてそれが望ましい-はおそらくその考えの結果ですが、彼がしている重要なポイントは問題を評価する方法です。プログラムは通常、問題の解決策であり、「懸念の分離」を提唱することで、賢明なアドバイスを提供しています。この最も良い例は、おそらく「最適化」です。冗談は、「プログラムを最適化する計画を立てるときの最初の戦略は、すべきではない」でした。つまり、最初にプログラムを正しくすることに集中したいと考えています。それを速くて派手なものにすることは分離すべき問題ですが、完全に取り除くこともできません。

懸念の分離は、関連する必要がないものを個別に検討することからなる抽象的な考え方です。

モジュール化（無関係な機能のグループをモジュールに分離する）、カプセル化（モジュールの内部の詳細を隠す）、および抽象化（一般から特定の概念を分離し、その実装からアイデアを分離する）はすべて、この考え方をドメインに実装する手段ですソフトウェア設計の。

この論文は歴史的に興味深いものですが、40年以上前の「懸念の分離」という用語でダイクストラが意味していたことは、今日は特に重要ではありません。今日では、モジュール化に関して広く使用されています。

モジュール化が非常に有益であり、それらのメリットが、それが私たちに課す「負担」をはるかに上回ることを示す豊富な証拠があります。その当時のダイクストラの意味が何であれ、それぞれが1つだけに焦点を当てた小さなコードのチャンクが、コードの作成、読み取り、理解、維持、テストが容易になるという事実は変わりません。

私は、ダイクストラの概念に匹敵すると思う個人の懸念の分離の例を挙げましょう。ソフトウェアで特定の主題を分析するとき、3つのビューを作成します。

1. まず、データについて考えます。データは問題の論理的な述語を表します。クラスは、現実のエンティティを抽象化するために構築され、その属性は抽象化のパラメータです。クラス間の関連付けは、クラスインスタンス間の機能マッピングを表します。この時点では、思考に関係するコードはなく、処理の概念もありません。主題に関係するロジックの静的なビュー。
2. 次に、ダイナミクスを検討します。重要なライフサイクルを持つクラスは、有限状態機械としてモデル化されます。これには、シーケンスの実行と同期の考慮事項が含まれます。繰り返しになりますが、物事がどのように相互に作用し、シーケンスするかをうまく処理するコードはありません。
3. 第三に、処理を検討します。ここでは、状態遷移時または他の同期操作で実行する必要がある実際のアルゴリズム作業。

最後に、主題の3つのファセットビューを取得します。このビューは、コード自体とそのメンテナンスに便利なグループにコードとして定式化できます。3つの側面は単なる精神的な運動ではありません。私はすべての面の記述を作成します。どうして？なぜなら、主題が十分に大きいと、完全なファセットを1つでも短期記憶に保持できないからです。主題が小さい場合は、すべてを頭に抱えることができるため、ほとんどすべてのアプローチが機能します。

懸念を分離する動機は、人間の短期記憶制限に対応することです。コンピュータープログラマーは、他の多くの人々よりも短期記憶の中で操作できる概念の数が多くなる傾向がありますが、私たちは頭の中ですべてを一度に運ぶことはできません。効果的にするには、懸念事項を体系的に分離する必要があります他の特定の側面に焦点を当てるために、問題の1つ以上の側面を除外します。もちろん、1つの側面を除外しても、検討対象から外れることにはなりません。すべての問題の側面を組み合わせて解決策を達成する手段がなければなりません。多くの場合、分離と再結合の最終結果は、多くの側面が混ざり合う可能性のある単一の巨大な飛躍よりも理解可能な解決策をもたらすことがよくあります。これは特に、問題のサイズが大きいか複雑な場合に当てはまります。

関心事の分離は論理的な概念であり、実装方法に関係なく、コード編成モデルに反映されます。コードファイルは技術的な詳細であり、ソフトウェアを管理しやすくするための1つの方法であることは事実です。リージョンの展開を折りたたむことができる優れたエディタを備えた単一のファイルでも、（しばらくの間）機能する場合があります。または、クラスとメソッドを親子の方法で別々のテーブルに格納するリレーショナルデータベースは、ストレージメディアとして機能します。しかし、テキストファイルは、ソースコードを

• ポータブル
• さまざまな外部ツールからアクセス可能
• 複数のプログラマーがアクセス可能
• バージョン可能で比較可能
• ファイル処理が非常に優れているオペレーティングシステムに適切に対応

要するに、私たち人間は一度にさまざまなことを考えたり処理したりすることがあまり得意ではないということです。したがって、現時点では考慮していない他の部分を台無しにする危険を冒すことなく、一度に1つのことを考えて取り組むことができるモデルが必要です。したがって、私たちは一度に1つのレンガを設置し、先に設置したレンガが後で設置するレンガと干渉しないようにします。そして、後でレンガを変更したい場合、物事は崩壊してはなりません。それは私たちのワントラックマインドのために働くモデルです。

これは真菌や藻類が成長する方法ではありません...謙虚な事実はどうですか？

しかし、ダイクストラの引用に対する具体的な回答は扱われたと思いますが、「最新のOOを使用すると、データアクセスを独自のファイルに配置できます」と述べ、「懸念の分離は、物理的ではなく精神的な練習のままにするべきか」と質問しました。現代のOOプリンシパルが私たちをどこに向けるかに注意を向けさせてください。

OOを使用した開発では、SOLIDの原則に従う必要があります。ここにそれらのための素晴らしいリンクがありますが、「懸念の分離」に関するTLDRは、主にSOLIDのS：単一責任原則またはSRPにあります。

これは、間違いなく、肉体的な運動であり、精神的な運動ではありません。具体的な例として、MVC（または兄弟のMVVMとMVP）は、モデル、ビュー、コントローラー/プレゼンター/ビューモデルのコンサートを物理的に別々のファイルに分離するように指示します。「概念を混同」する傾向をさらに制約するために、これらが個別のアセンブリに実装されるMVVM実装をいくつか見ました。

だが。ボブおじさんの見方をすれば、「これはビューであり、これはモデルです」という単なる単純な話を超えています。

特定のオブジェクト指向要素の要件のソースも考慮する必要があります。たとえば、顧客が望んでいるものと運用担当者が望んでいるものを混在させている場合は、SRPにも違反しています。または、ボブおじさんがするようにそれを置くために：クラスは変更する唯一の理由を持つべきです。

提供されたリンクを使用してこれをさらに調査するか、「確実な原則」をWeb検索することを強くお勧めします。