抱える責任を分離していきます。ユーザー配列の取得と、その状態の保持をAppComponentから取り除くことにしましょう。Angularにおけるサービスという語彙は、特定の実装やインターフェースの名称ではなく、ある単一の関心のための作られた機能集約のことをまとめてサービスと呼びます。HTTP経由でユーザーの配列を取得する処理を、UserServiceに移譲しましょう。この処理をAppComponentから隠蔽することで、URLの変更やHTTPヘッダの追加のような原因でAppComponentが変更されることがなくなります。メソッドを呼び出すだけとなります。}}​AppComponentの責務がどんどん減ってきましたね。RxJSによる状態管理ユーザーリストを表示するための配列はAppComponentのクラスプロパティとして保持されています。移譲するにあたり、UserServiceのメソッドを次のように整理します。従ったものになっています。HTTPリクエストを発行する副作用がある一方で呼び出し元に結果も返しています。これを分離し、HTTPリクエストを発行してシステムの状態を書き換えるコマンドと、システムの状態を監視するクエリを作成します。このSubjectは常にスナップショット可能な状態を保持できるため、シンプルな状態管理に最適です。サービスの利用者には読み込み専用のObservableとしてのインターフェースだけを露出したいので、プライベートフィールドとgetterを使って実装します。}}このサービスをAppComponentから利用すると次のようになります。注意すべきは、ユーザーの配列が同期的な配列からObservableに変わったので、テンプレート中でAsyncパイプを使って購読する点です。async"></user-list>ついに、UIとライフサイクルに関わる責務以外はすべてAppComponentから分離できました。ところで、今のAppComponentとUserServiceの関係を図にすると次のようになります。みるとこれはビューとストア、アクションによる単方向のデータフローを構成しており、簡易的ではありますがFluxに近い実装となっています。UserService現在は管理する状態がユーザーの配列だけですが、アプリケーションの状態が増えるとUserServiceだけで管理することが単一責任の原則に反していきます。次のページからは少し複雑性が高くなっていくなかでのアプリケーション設計を学びましょう。GitHubContentsUserServiceRxJSによる。