インターネットプロトコルスタックエディット

懸念の分離は、インターネットの設計に不可欠です。 インターネットプロトコルスイートでは、懸念事項を明確に定義された層に分離するために多大な努力が行われています。 これにより、プロトコル設計者は、ある層の懸念に焦点を当て、他の層を無視することができます。 たとえば、アプリケーション層プロトコルSMTPは、信頼性の高いトランスポートサービス(通常はTCP)を介して電子メールセッションを実行するすべての詳細に関 同様に、TCPはインターネット層で処理されるデータパケットのルーティングについては関心がありません。

HTML、CSS、JavaScriptEdit

ハイパーテキストマークアップ言語（HTML）、カスケードスタイルシート（CSS）、およびJavaScript（JS）は、webページやwebサイトの開発に使用される補完的な言語です。 HTMLは主にwebページコンテンツの構成に使用され、CSSはコンテンツの表示スタイルの定義に使用され、JSはコンテンツがユーザーとどのように相互作用し、 歴史的に、これはそうではありませんでした：CSSの導入前に、HTMLはセマンティクスとスタイルを定義する義務の両方を実行しました。

Subject-oriented programmingEdit

Subject-oriented programmingは、別々の懸念を別々のソフトウェア構成として対処することを可能にし、それぞれが他のものと同等の立場にある。 それぞれの関心事は、共通のオブジェクトが編成された独自のクラス構造を提供し、状態とメソッドが互いに切断された複合結果に貢献します。 対応ルールは、さまざまな懸念のクラスとメソッドが相互作用する点で互いにどのように関連しているかを記述し、メソッドの複合動作をいくつかの 懸念の多次元分離は、各懸念が選択の異なる点が列挙されている次元を提供する多次元”行列”として操作することができ、行列のセルは適切なソフ

Aspect-oriented programmingEdit

Aspect-oriented programmingは、横断的な懸念を主な懸念として対処することを可能にします。 たとえば、ほとんどのプログラムでは、何らかの形式のセキュリティとログ記録が必要です。 セキュリティとログ記録はしばしば二次的な懸念事項ですが、主な懸念事項はビジネス目標の達成にあることがよくあります。 しかし、プログラムを設計するとき、そのセキュリティは二次的な懸念として扱われるのではなく、最初から設計に組み込まれなければなりません。 その後にセキュリティを適用すると、セキュリティモデルが不十分になり、将来の攻撃にはギャップが多すぎます。 これはアスペクト指向プログラミングで解決することができます。 たとえば、プログラムの手続き型コードが例外を処理するか伝播するかにかかわらず、特定のAPIへの呼び出しが常にログに記録されること、または例外

人工知能における分析のレベル

認知科学と人工知能では、David Marrの分析のレベルを指すのが一般的です。 任意の時点で、研究者は、（1）知性のある側面が計算する必要があるもの、（2）それが採用するアルゴリズム、または（3）そのアルゴリズムがハードウェアでどのように実装されているかに焦点を当てている可能性があります。 この懸念の分離は、ソフトウェア工学とハードウェア工学におけるインターフェイス/実装の区別に似ています。

正規化されたシステム編集

正規化されたシステムでは、懸念の分離は、四つの指導原則の一つです。 この原則を遵守することは、時間の経過とともに、維持されているソフトウェアに導入される組み合わせ効果を減らすのに役立つツールの1つです。 正規化されたシステムでは、懸念の分離はツールによって積極的にサポートされています。

SoC via partial classesEdit

懸念の分離は、部分クラスを介して実装および強制することができます。P>

RubyEditの部分クラスを介したSoC

bear_hunting。rb

class Bear def hunt forest.select(&:food?) endend

bear_eating。rb