1. 導入：なぜ循環参照は「悪」なのか
数値計算プログラムにおいて、モジュール間の依存関係はコードの可読性と保守性を左右する重要な要素です。特にFortranなどのコンパイル型言語では、モジュールAがBを参照し、BがAを参照する「循環参照」が発生すると、コンパイル順序が決定できず、ビルドが失敗します。これは単なるエラーではなく、設計の階層構造が破綻しているサインです。本稿では、この課題を解決するための設計指針と実装テクニックを解説します。
2. 基礎知識：依存の方向性を理解する
モジュール設計の鉄則は「依存の方向を一方通行にする」ことです。例えば、物理定数モジュールを「下位層」、計算アルゴリズムモジュールを「中位層」、メインプログラムを「上位層」と定義する場合、依存関係は常に「上位が下位をUSEする」形であるべきです。循環参照は、この階層を無視して下位から上位を呼び出そうとした時に発生します。これが起きると、コンパイラは「どちらを先にビルドすべきか」を判断できず、循環依存の警告やエラーを返します。
3. 実装/解決策：論理的階層の再構成とSUBMODULEの活用
循環参照を回避する代表的な手法は以下の2点です。
1. 共通機能の切り出し：相互に依存している関数を「第3のモジュール」に切り出し、AとBの両方がその新モジュールをUSEするように修正します。
2. SUBMODULEの使用：Fortran 2008以降であれば、インターフェース定義と実装を分離できます。モジュールでインターフェースのみを定義し、個別のSUBMODULEで実装を行うことで、依存関係の複雑さを緩和できます。
4. サンプルプログラム：共通機能の抽出による回避
以下は、循環参照が発生する設計を、共通モジュールを作成することで解決する例です。
! — 修正前：循環参照が発生する危うい設計 —
! module A; use B; … end module A
! module B; use A; … end module B
! — 修正後：共通機能 C を作成して依存を解消 —
module Constants_Mod
! 共通の定数や型定義をここに集約
implicit none
real, parameter :: PI = 3.1415926535
end module Constants_Mod
module Solver_A_Mod
use Constants_Mod
implicit none
contains
subroutine solve_a()
print , “Solver A: PI is”, PI
end subroutine solve_a
end module Solver_A_Mod
module Solver_B_Mod
use Constants_Mod
implicit none
contains
subroutine solve_b()
print , “Solver B: PI is”, PI
end subroutine solve_b
end module Solver_B_Mod
program main
use Solver_A_Mod
use Solver_B_Mod
! メインプログラムから各モジュールを呼び出す構成にする
call solve_a()
call solve_b()
end program main
5. 応用・注意点：現場で陥りやすい罠
現場での開発において、ついやってしまいがちなのが「便利な関数をどこにでも置けるようにする」という安易な設計です。これが進むと、プロジェクトの終盤で巨大な循環依存のスパゲッティコードが出来上がります。
回避のコツは、「循環が発生しそうになったら、それは設計を見直すべきサインである」と認識することです。もしどうしても分割できない複雑な依存がある場合は、データ構造を構造体（Derived Type）として別モジュールに分離し、計算ロジックとデータ定義を完全に切り離す「カプセル化」を徹底してください。これにより、依存関係を常に単方向に保つことができます。
コメント