私はオペレーティング システムの教科書を読んでいて、「メカニズムとポリシーを分離する」という概念に出くわしました。それが何を意味するのかわからなかったので、認めざるを得ないウィキペディアをチェックアウトしましたが、あまり役に立ちませんでした.
メカニズムとポリシーの分離 [1] は、コンピューター サイエンスの設計原則です。メカニズム (操作の承認とリソースの割り当てを制御するシステム実装の部分) は、どの操作を承認し、どのリソースを割り当てるかについての決定に応じて、ポリシーを決定 (または過度に制限) すべきではないと述べています。 .
誰かがこれを控えめにして、可能であればいくつかの例を挙げてseparation of mechanism and policy、オペレーティング システムのコンテキストで何を意味するかを説明できますか?
これが X-Windows システムにとって何を意味するかを次に示します。
X-Windows は、非常に基本的なレベルで、「ウィンドウ」と呼ばれる画面領域を操作する方法を提供します。また、ウィンドウ内で発生するイベントを受け取る方法も提供します。
しかし、X-Windows は、タイトル バー、メニュー、スクロールバーなどについては何も言いません。また、特定のアプリケーションがそのウィンドウを画面全体に表示させる規則や、ウィンドウを画面外に移動する必要がある場合についても何も述べていません。1 つのアプリケーションが、トップレベル ウィンドウで処理を行う前に他のアプリケーションに許可を求めるように強制する方法を提供しますが、ベース サーバーの一部としてそのようなアプリケーションを提供しません。
X-Windows は、ポリシーではなくメカニズムがすべてです。
ポリシーは、ウィジェット ツールキット、ウィンドウ マネージャー、および後でシステムに追加されるその他のものによって提供されます。たとえば、多くのウィジェット ツールキットは、スクロールバーにオーバーラップするサブウィンドウのセットを使用し、これらのサブウィンドウのマウス イベントを要求して、クリック アンド ドラッグ操作を検出し、サブウィンドウを適切に応答させることができます。
これが、たとえば、GNOME と KDE が同じディスプレイでうまく機能する理由であり、パネルやデスクトップについて何も知らない非常に古い X-Windows プログラムが最新のシステムで問題なく動作する理由です。
*nix オペレーティング システムに関しては、一般的な考え方として、セキュリティ システムはカーネルによって実装され、認証システムはユーザー空間によって実装されます。
非常に多くの人々が（正当かどうかにかかわらず）嘲笑している強力な root および suid バイナリは、効果的な分離に必要です。セキュリティをそのままにして、認証メカニズムを完全に入れ替えることができます (ssh はこれを行います。これが、Windows で文書化されていない API を使用する理由です)。
これは非常に古い質問ですが、それでも私の主張を共有したいと思います。
この一節がややこしいのは、「メカニズム」と「ポリシー」という 2 つの言葉があるためです。また、ソフトウェア エンジニアリングの文脈では、「メカニズム」を「インターフェース」に、「ポリシー」を「実装」に置き換えることは常に問題ないと思います。
インターフェースと実装の分離に関しては、Java でプログラミングしている場合は、これら 2 つの概念に精通している必要があります。そうすることで、「何をするか」と「どのように行うか」を切り離すことができ、システムのデカップリングを実現するのに役立ちます。
デカップリングする理由 デカップリングにより、コードの拡張性と保守性が向上します。つまり、要件が変更されたときに記述するコードを減らすことができます:)
「The GoF Design Patterns」からデカップリングのテクニックを学んでください。
Difference between mechanism and policy mechanism determines how to do something, policies decide what will be done.
The separation of policy from mechanism is very important principle, it allows maximum flexibility if policy decisions are to be changed later.