web-dev-qa-db-ja.com

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

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

私の趣味はすべてのインテリジェントな思考に特徴的です。それは、自分の一貫性を保つために、自分の主題の側面を分離して詳細に研究することをいとわないことであり、常に、側面の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>

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

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

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

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

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

designsource-codeseparation-of-concernsmodularizationdijkstra
9
Dennis

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

2
MCL

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

Modularization（モジュールの関連しないグループをモジュールに分離）、カプセル化（モジュールの内部の詳細を隠す） 、および抽象化（一般から特定、およびその実装からのアイデアを分離する）はすべて、ソフトウェア設計の領域でこの考え方を実装するための手段です。

14
Christophe

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

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

9
David Arno

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

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

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

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

2
andy mango

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

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

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

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

1
Martin Maat