手続き型アーキテクチャの課題

手続き型プログラミングは、タスクを直線的なステップとして設計するアプローチです。複雑な処理を段階的に分解することで実装が容易になる反面、機能追加や修正時に複数の処理ユニットを連動して変更しなければならない「密結合」な構造になりがちです。

def capture_credentials():
    user_id = input("Username: ").strip()
    secret = input("Password: ").strip()
    if not user_id or not secret:
        print("エラー: 必須フィールドは空にできません。")
        return
    
    # 拡張時にここと後続処理の両方を修正する必要がある
    role_map = {"1": "administrator", "2": "regular"}
    selected_role = input("ロールを選択: ").strip()
    if selected_role in role_map:
        role_name = role_map[selected_role]
        process_registration(user_id, secret, role_name)
    else:
        print("エラー: 無効な選択です。")

def process_registration(uid, pwd, role):
    record = f"{uid}|{pwd}|{role}\n"
    write_to_storage(record)

def write_to_storage(payload):
    with open("accounts_db.txt", "a", encoding="utf-8") as file:
        file.write(payload)
    print("登録処理が完了しました。")

capture_credentials()

上記の例では、新しい属性（例：メールアドレス）を追加するだけで、入力処理、データ整形、ストレージ書き込みの全レイヤーを修正する必要があります。この非効率性を解消し、コードの再利用性を高めるために、Pythonでは機能のカプセル化を促進する「モジュール」が標準的に採用されています。

モジュールの定義と構成

モジュールは、特定の目的に関連するコード、データ、または機能を単一のユニットとしてまとめたものです。外部実装や標準ライブラリを活用することで、ゼロからの実装コストを大幅に削減できます。

• 標準ライブラリ: Pythonインタプリタにバンドルされており、追加設定なしで利用可能です。
• サードパーティ製: pip などのパッケージマネージャを通じてインストールする外部開発者が公開したライブラリです。
• カスタム: 開発者がプロジェクト内で独自に作成したスクリプトやパッケージです。

物理的な形態としては、.py ファイル、コンパイル済みのC/C++拡張モジュール、複数のモジュールを含むディレクトリ（パッケージ）、およびインタプリタに統合されたビルトインコンポーネントなどが挙げられます。複雑なロジックを実現する際、既存モジュールの利用をまず検討することはソフトウェア開発の重要な原則です。

インポートメカニズムと名前空間

Pythonはモジュールの読み込み時に厳格な名前空間管理を行います。同じスクリプト内で重複したインポートが実行されても、内部的にキャッシュされ、実際のコード実行は初回のみ発生します。

import 文の実行フロー

import target_module

1. 呼び出し元スクリプトでグローバル名前空間が生成されます。
2. 指定されたモジュールファイルが実行され、独立したグローバル名前空間が構築されます。
3. 呼び出し元の名前空間内に、モジュールオブジェクトへの参照（target_module）が格納されます。

この方式では、target_module.function_name() のように修飾子を使用してアクセスするため、ローカル変数やグローバル変数との名前の衝突を完全に回避できます。

from ... import ... 文の実行フロー

from target_module import specific_function

1. 呼び出し元およびターゲットモジュールの名前空間が生成されます。
2. ターゲットモジュールが実行され、内部定義が評価されます。
3. 指定されたシンボル（specific_function）の値が、呼び出し元のグローバル名前空間に直接コピーされます。

修飾子なしで直接呼び出せる利点がありますが、ローカルスコープに同名の定義が存在すると、意図せず上書きされる（シャドウイング）リスクがあります。

高度なインポート制御

• エイリアス: 長いモジュール名や衝突回避のために名前を再定義します。
  import complex_lib as cl
from utils import helper as h
• 複数モジュールの読み込み: 可読性とデバッグ容易性を維持するため、別々の文で宣言するのがベストプラクティスです。
  import os
import sys
• ワイルドカードインポート: from module_name import * は内部シンボルをすべてエクスポートしますが、名前空間の汚染を招きます。これを制御するには、モジュール内で __all__ = ['func_a', 'class_b'] と明示的に公開範囲を定義します。定義されていないシンボルはワイルドカードインポートでは取得されません。

実行コンテキストの判別（__name__）

Pythonスクリプトは、直接実行される場合とインポートされる場合で振る舞いを切り分けることができます。__name__ 組み込み変数は、スクリプトがトップレベルとして実行されると "__main__" を返し、モジュールとして読み込まれた場合はファイル名（拡張子なし）を返します。

if __name__ == "__main__":
    print("直接実行モード: テストケースを実行中")
    run_unit_tests()
else:
    print("モジュールとしてインポートされました")

このパターンは、インポート時に副作用（HTTPリクエスト、ファイル書き込み、重い計算など）が発生しないようにするための標準的なガードとして広く利用されています。IDEによっては main と入力してTabキーを押すだけでこのテンプレートを自動生成できます。

サイクリックインポートの回避

モジュールAがモジュールBを、モジュールBがモジュールAを相互にインポートすると、名前空間の初期化が完了する前に参照エラーが発生します。これはアーキテクチャ上の設計不良を示す兆候であり、可能な限り排除すべきです。

• インポート順序の最適化: 相互依存するインポート文をファイル末尾、または関数・メソッドの内部（ローカルインポート）に移動させます。これにより、必要な名前が完全にロードされた後にアクセスが可能になります。
• 依存関係の解消: 共通の抽象レイヤーやイベントバスを介して疎結合に設計し直すのが根本的な解決策です。

モジュール検索パスとディレクトリ構成

インポート要求が発生すると、インタプリタは以下の順序で検索を実行します。

1. メモリ内のキャッシュ（sys.modules）
2. ビルトインモジュール
3. sys.path に登録されたディレクトリ一覧

sys.path の先頭には常に実行スクリプトの存在するディレクトリが配置されます。カスタムモジュールが検出されない場合、絶対パスを手動で追加するか、パッケージ構造を活用します。

import sys
sys.path.append("/absolute/path/to/custom/lib")
import my_custom_module

階層が異なる場合のインポート構文は以下の通りです。

• サブディレクトリ内からの読み込み:
  from subpackage import target_script
from subpackage.target_script import specific_func
• 上位ディレクトリへの参照: プロジェクトルートをPythonパスに登録するか、python -m package.module 形式で実行することで、相対パス解決を安定化させます。
• 名前衝突の回避: 自作モジュールのファイル名が標準ライブラリ（例: os.py, math.py）と一致しないように注意してください。衝突が発生すると、ビルトインモジュールが優先されて期待通りに動作しなくなります。