関心の分離

ウィキペディア

関心の分離

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2023/11/22 01:57 UTC 版)

関心の分離（かんしんのぶんり、英語: separation of concerns、SoC）とは、ソフトウェア工学においては、プログラムを関心（責任・何をしたいのか）毎に分離された構成要素で構築することである。

プログラミングパラダイムは開発者が関心の分離を実践することを手助けするものもある。その為には、モジュール性とカプセル化の実装のしやすさが重要となる。

関心の分離は複雑で依存関係が入り乱れたシステムの理解・設計・運用を容易にすることが出来るので他の工学分野でもみられる。

歴史

「関心の分離」を意味する英語「separation of concerns」は、エドガー・W・ダイクストラが1974年に論文「On the role of scientific thought」（Dijkstra 1974: 科学思想の役割）で初めて使用したとされている。1989年にChris Reade が「Elements of Functional Programming」（Chris Reade 1989: 関数型プログラミングの要素）というタイトルの書籍で関心の分離を説明している。

例

関心の分離の例として構造と見た目の分離（英：separation of presentation and content）がある。

React: ライフサイクルメソッド/時間的凝集とhook/機能的凝集

以降、ReactというJavaScriptライブラリ( メタとコミュニティにより開発 )での例を挙げる。このライブラリには、ライフサイクルメソッド という考え方を持っている。ライフサイクルメソッドがもたらした機能的凝集度の低さをhookによって克服し、SoCを実現している。

ライフサイクルメソッドは周期（ライフサイクル）のある時点で自動的に呼び出されるメソッドである。例えばコンストラクタはインスタンス作成時のメソッドであり、onMemberChangedメソッドはメンバ更新時に毎回呼び出されるメソッドである。ライフサイクルメソッドとして時間的に適切な処理を実装すれば、ある時点でおこなわれる処理が一か所に集約され時間的凝集度が高いコードになる（時間的なSoCがおこなわれている）。

例えばタイマー2つによるカウントダウンUIを考える。ライフサイクルメソッドを利用する場合、開始時（constructor）でcount変数を用意し、UI作成時（componentDidMount）にタイマーをセットし、レンダリング時（render）にカウント表示を更新、UI破棄時（componentWillUnmount）にタイマーを破棄する。

class Clock extends React.Component {
  constructor(props) {
    super(props);
    this.state = { countA: 0, countB:0 };
  }

  componentDidMount() {
    this.timerIDa = setInterval(() => this.tickA(), 1000)
    this.timerIDb = setInterval(() => this.tickB(), 1000)
  }

  componentWillUnmount() {
    clearInterval(this.timerIDa);
    clearInterval(this.timerIDb);
  }

  tickA() {
    this.setState({ countA: this.state.countA + 1});
  }
  tickB() {
    this.setState({ countB: this.state.countB + 1});
  }

  render(){
    return <div>now count: A/{this.state.countA} - B/{this.state.countB}</div>
  }
}

ある時点で何が起きるかが一見してわかる（時間的凝集度が高い）一方、機能的に見ると一連の処理を時間ごとに別の関数に切り出していることになる。また1つのサイクルメソッドの中にタイマーAの処理とタイマーBの処理が混在することになる。このようにライフサイクルメソッドを用いたコードは時間的凝集度が高くても機能的凝集度は低いといえる。 そこでReactでは機能的凝集度を高めるhookと名付けられた機能を導入した。hookはライフサイクルメソッドのようなclass interface実装ではなく、関数の暗示的状態（非透過的な参照）を利用している。コンポーネントあたり1つしか持てないライフサイクルメソッドと異なり、関数であるhookは何度でも利用ができる。また各hook関数が状態の保持やライフルサイクルの管理といった個別機能を持つため、機能Aに必要なすべてのhookを1箇所に集めることができる。すなわち機能的凝集度が高い状態、機能的なSoCが実現できる。

function Clock() {
  // Timer A /////////////////////////////////////////
  const [countA, setCountA] = useState(0);
  useEffect(()=>{
    const id = setInterval(() => setCountA(n=>n+1), 1000);
    return ()=> clearInterval(id)
  }, []);
  // Timer A /////////////////////////////////////////

  // Timer B /////////////////////////////////////////
  const [countB, setCountB] = useState(0);
  useEffect(()=>{
    const id = setInterval(() => setCountB(n=>n+1), 1000);
    return ()=> clearInterval(id)
  }, []);
  // Timer B /////////////////////////////////////////

  return <div>now count: A/{countA} - B/{countB}</div>
}

"It can take input from the user and display information, but it should not manipulate the information other than to format it for display." p.96

プレゼンテーションとドメインの分離

プレゼンテーションとドメインの分離（英: Presentation Domain Separation）は「ユーザーインターフェースコードをその他のコードを分離する」という設計原則である^[1][2][3]。すなわちソフトウェアをプレゼンテーションとドメインという2つの関心に基づき分離するという原則である^[4][5]。

関心の分離により様々な利点が得られる。

• 特定の機能（PresentationかDomainか）に凝集したコードのみへの集中^[6]
• 分業と専門家の活用^[7]
• UIモジュールの切り替え^[8]
• ドメイン部分のテスタビリティ向上^[9]

明確な分離が必要になるか否かはソフトウェアの複雑性に依る^[10]。例えばデータがViewと完全に一致するのであればマッパーでSQLとViewを密結合に生成するライブラリが有用であろう^[11]。しかし複雑性が増すにつれプレゼンテーションとドメインを分離する上記の利点が大きくなる^[12]。

関連項目

• 凝集度
• 結合度

参考資料

• Multi-Dimensional Separation of Concerns
• TAOSAD
• Tutorial and Workshop on Aspect-Oriented Programming and Separation of Concerns
• Chris Reade (1989). Elements of functional programming. International computer science series.. Wokingham, England: Addison-Wesley. ISBN 0201129159. OCLC 19124943 
• Dijkstra, E.W. (1974). E.W. Dijkstra Archive: On the role of scientific thought (EWD447). http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html. 

1. ^ ^{a b c d e f g h i j k l} Fowler, M. (2001-03). “Separating user interface code”. IEEE Software 18 (2): 96–97. doi:10.1109/52.914754. ISSN 0740-7459. http://ieeexplore.ieee.org/document/914754/. 

脚注

1. ^ "Separating User Interface Code" p.96 ^{[g 1]}
2. ^ "separation of presentation and domain" p.97 ^{[g 1]}
3. ^ "refer to the user interface code as presentation code and the other code as domain code." p.96 ^{[g 1]}
4. ^ "Presentation and domain are two separable concerns I’ve found" p.97^{[g 1]}
5. ^ "The general principle here is that of separating concerns" p.97^{[g 1]}
6. ^ "A clear separation lets you concentrate on each aspect of the problem separately" p.96 ^{[g 1]}
7. ^ "It also lets different people work on the separate pieces, which is useful when people want to hone more specialized skills." p.96 ^{[g 1]}
8. ^ "Making the domain independent of the presentation also lets you support multiple presentations on the same domain code" p.96 ^{[g 1]}
9. ^ "Separating the domain code makes it much easier to test." p.97 ^{[g 1]}
10. ^ "For a simple set of pages, there is an overhead (although I would call it a small one)" p.97 ^{[g 1]}
11. ^ "the tools don’t provide any place to extract the domain code. If straight updates to data and view are all you do, then this is not a problem. ... However, once domain logic gets complicated, it becomes hard to see how to separate it." p.97 ^{[g 1]}
12. ^ "as the set gets more complicated, the value of the separation grows." p.97 ^{[g 1]}