名称と属性を見ても責務が分からない。

属性がないクラスは存在理由がありません。

まとまりのない複数の属性値を持つクラスは責務過多です。

メソッドは動詞句ひとつが理想です。メソッドで目的語（名詞句）が多いクラスも失敗です。

属性を見れば「クラスの責務が分かる」ことが理想です。

属性を単一目的にすることで凝集度が高まります。

組込み／IoTシステムでは「状態変数」を属性とすることで堅牢な設計になります。

getter/setterメソッドやisメソッド（問い合わせ）は責務を破壊するので好ましくありません。

自クラスの情報を外部に公開することになってしまいます。

クラスは状態を持ち、状態が連係することでメッセージ通信します。

２種のクラス設計レベルがあります。

■状態レスクラス設計

直線的に動くシナリオの設計に適しています。

過去の状態に関係なく処理を実行するプログラムです。

クラスを手続き的に書いてもそれなりに動きます。

並行動作や排他処理は利用するライブラリ側が行っていますので、

組込み／IoTシステムやPC上シミュレータなどには向いていません。

■状態連係クラス設計

クラスは状態変数を持ち、状態が遷移することでメッセージを発行します。

クラスごとの状態遷移図を作成し、状態の取りうる値を7個以内にします。

状態変数をデータ辞書で定義することも有効です。

　例：実行状態＝［準備中｜実行可能｜実行中｜停止中｜終了中］

現在状態にコインを置いて、イベントに対する状態遷移を検証するコインシミュレーションができます。

アドホックな状態実装としてフラグを用いることもありますが、オブジェクト指向設計とは言えません。

●状態フラグ設計

「フラグを立てて、後で条件判断する」という「状態」が必要なプログラムです。

手続き処理で必要な個所で条件判断していくこともできます。

しかし、フラグの数が多くなると入り組んだプログラムになるため、

複数のフラグが必要になった時点で、状態連係クラス設計を推奨します。