＆＃8220;状態設計パターン＆＃8221; ＆＃8220;アーキテクチャパターン＆＃8221;と考えることができますか？

Question

＆quot;アーキテクチャパターンは、ソフトウェアシステムの基本的な構造組織スキーマを表します＆quot;。

＆quot; アーキテクチャパターンの最初の段落で与えられた前述の説明を考慮すると、有限状態マシン（特に多くのリアルタイムシステムおよび組み込みシステム）として説明できるソフトウェアシステムがあります。 strong>＆quot ;、特定の場合に＆quot; state design pattern ＆quot; ＆quot; アーキテクチャパターン＆quot;にすることもできますか？

「state design pattern」に関係するジュニア開発者と設計文書を議論するときにこの質問を受けました。この質問に「はい」と答えました。「状態設計パターン」 「アーキテクチャ設計パターン」と見なすことができます。アプリケーションは主に有限状態マシンであるためです。とにかく、Googleで見ると、この質問に関連する特定のディスカッションが見つからないため、答えが正しかったかどうかわかりません。

正しい答えは何ですか（答えることが可能な場合）。 回答の根拠は何ですか？

よろしく。

Answer 1

これは非常に主観的な質問であり、正しい答えを与えることはできません。

今、この午前中、雨天が外にあるので、ステートマシンはあまりアーキテクチャパターンではないことを提案したいと思います。ステートマシンは、アプリケーションの動作のダイナミクス、アプリケーションが1つの状態にあり、別の状態に移行するための前提条件と条件を定義します。

構造的な組織は、主に静的コンポーネント、それらが何であるか、どのように相互接続されているか、その役割は何かを扱います。ステートマシンは、単にコンポーネントの1つと見なすことができます。

または、検討する価値がある唯一のシステムのコンポーネントと見なすことができます。その場合は、アーキテクチャパターンと見なされる可能性があります。

私が言ったように、正しい答えも間違った答えもありません。

Answer 2

＆quot;デザイン＆quot;通常、「アーキテクチャ」よりも小さなスケールで物事を指し、ステートマシンは通常小さなコンポーネントであるため、私の意見ではデザインパターンが正しい分類です。

システム全体をカバーする相互作用するステートマシンのパターンがある場合、それは別の話かもしれません。

（かなり曇りの週の後、ここは晴れています。）