torikatsu.dev

Flutterとかプログラミングとかガジェットとか書きます

Flutterの文脈におけるアーキテクチャと状態管理のパターンと状態管理の手法の違い

こんにちは、とりかつ(@torikatsu923)です。 Flutterは状態管理の手法が数多くあり、状態管理の手法は日々進化しています。 それゆえ、最新の情報に敏感になる必要があり、私は日々色々な記事を読み漁っています。

そんな中でふと、Flutterの状態管理周りの記事は、アーキテクチャと状態管理のパターンと状態管理の手法が一緒くたに論じられることが多いと思いました。 そこで今回の記事では、Flutterという文脈でアーキテクチャと状態管理のパターンと状態管理の手法の違いについて整理していこうと思います。

アーキテクチャと状態管理のパターンと状態管理の手法の違い

私は違いについて以下のように考えています。

用語 説明
アーキテクチャ アプリケーションのプログラム構造
状態管理のパターン アプリケーションの状態を管理するためのプログラム構造
状態管理の手法 状態管理のパターンを実現するための実装手段

これらは階層構造になっています。と言ってもピンと来づらいのでで図にしてみました。

f:id:torikatsu923:20210420233213p:plain
図解

アーキテクチャにはさまざまなものがあります。 フロントエンドのアプリケーションにおいて、もっとも関心が高いことは、複雑なアプリケーションの状態をどのように管理するかということです。 Flutterはフロントエンドのフレームワークなので、Flutterという文脈では、アーキテクチャ=状態管理のパターンと捉えることができます。 この切り口で線引きをすると、MVVM、MVC、Flux等が該当するアーキテクチャになります。

そして、MVVMやMVC、Fluxのようなフロントエンドのアーキテクチャを実現するための手段としてriverpodやbloc、fluxパッケージがあると考えることができます。

おわりに

短いですが、Flutterの文脈におけるアーキテクチャと状態管理のパターンと状態管理の手法の違いについて整理してみました。 この記事が状態管理の記事を読み解く手助けになれば幸いです。

本記事は個人的な考え方による部分が強いです。その点についてご了承ください。 記事の質を向上させ、正しい知見を広めたいと考えているので、もしご意見等あればコメントいただけると幸いです。