1.3コード構成と設計パターン

自動化スクリプトは放っておくと、取得・加工・表示・通知がすべて1つの長い処理に混ざった「一枚岩」に育ちます。すると1か所直すたびに別の場所が壊れ、テストもしづらくなります。この節では、再利用と変更のしやすさの観点でコードを関数・クラス・モジュールへ分ける考え方と、責務の分離を体系化したMVC、変化の通知を疎結合で実現するObserverを、「この状況ではどう構成/どのパターンが適切か」という設計判断として学びます。名前の暗記ではなく、目の前のコードの臭いを嗅ぎ分け、適切な分割を選べることが目標です。

1.3.1関数・クラス・モジュール

• 関数（function）＝入力を受け出力を返す再利用可能な処理の単位。同じ手順の重複を1か所に集約し、名前で意図を表す。メソッド（method）はクラスに属する関数で、そのオブジェクトの状態（属性）に対して動作する。まず「重複した処理は関数へ」が構成の第一歩。
• クラス（class）＝関連するデータ（属性）と振る舞い（メソッド）をひとまとめにする設計図。例えばDeviceクラスにname/ip属性とconnect()/get_config()メソッドを持たせる。状態と操作が結びつく対象はクラスにすると、散らばった変数と関数より扱いやすい。
• モジュール/パッケージ＝関数やクラスをファイル/ディレクトリ単位でまとめ、importで再利用する仕組み。役割ごとにファイルを分ける（例：API通信、データ整形、出力）ことで、変更の影響範囲を局所化し、テスト対象を切り分けられる。

1.3.2設計パターン：MVCとObserver

• MVC＝Model（データとビジネスロジック）・View（表示）・Controller（入力を受けてModelとViewを仲介）に責務を分ける。取得ロジックと画面表示が混ざったコードをMVCに沿って分けると、表示だけ差し替える・ロジックだけテストする、が容易になる。
• Observer（オブザーバ）＝ある対象（subject）の状態が変わったら、登録済みの購読者（observer）へ自動通知するパターン。1対多の通知を疎結合で実現し、購読者の追加/削除が対象側のコードに影響しない。イベント駆動のwebhook的な「変化があったら知らせる」要件に合う。

あなたは、機器からインタフェース情報を取得してターミナルに表を描く一枚岩スクリプトの保守を引き継ぎました。1つの長いmain()の中で、APIへのHTTP呼び出し・JSONの整形・色付きの表描画・ファイルへのログ出力がすべて混ざっています。「表の代わりにWeb画面でも出したい」「取得ロジックだけ自動テストしたい」という要望が来ますが、今の構造では表示を変えるとロジックにも手が入り、テストのたびに実機へアクセスしてしまいます。ここで適切な判断は、MVCに沿って責務を分けることです。機器から取得しデータを保持・加工する部分をModel（実機依存は関数化してモックに差し替え可能に）、表やWeb画面など見せ方をView、要求を受けてModelを呼びViewへ渡す司令塔をControllerに切り出します。こうすると、Viewを表からWebに替えてもModelは無傷で、Modelのロジックだけをユニットテストできます。さらに「インタフェースがdownに変わったら、ログ・アラート・ダッシュボードの3か所へ同時に知らせたい」という要件が加わったとします。通知先が増えるたびにModel内へifを足すのは密結合で壊れやすい——ここはObserverが適任です。状態変化（down検知）を起こすsubjectに購読者（ログ/アラート/ダッシュボード）を登録しておけば、変化時に一斉通知でき、購読者の増減はsubjectのコードに影響しません。逆に、単純な一度きりの整形処理にまでパターンを持ち込むのは過剰設計です。要は、コードの臭い（重複・混在・変更波及）を読み、関数/クラス/モジュールという構成とMVC/Observerというパターンのどれが今の痛みを解くかを選ぶ判断が核心です。

1.3.3この節のまとめ

• 重複処理は関数へ、状態＋操作はクラスへ、役割ごとにモジュール分割して変更の影響を局所化する
• MVCはModel(ロジック/データ)・View(表示)・Controller(仲介)で責務を分け、表示差し替えとロジックのテストを容易にする
• Observerは状態変化を事前登録した購読者へ1対多で疎結合に通知する。過剰設計を避け、痛みに合う構成/パターンを選ぶ