Mluvím-li o modulu, mám na mysli abstraktní modul, tedy v podstatě jakýkoliv objekt s převažující lokální komunikací.
Tak tohle je imo jedna z horších definic toho, co to je modul. Nejmíň u poloviny modulů, co jsem kdy napsal nebo použil tu převažující lokální komunikaci fakt nevidím.
Tak záleží jak tu komunikaci definujete, komunikaci si můžete představit jako fyzické doručení balíčku na nějakou adresu a nebo taky jako změnu svého jednání na základě nějaké informace, kterou jste přijal. Modul tedy až na přesně popsané výjimky, používá ke změně svého stavu lokální informace.
Pokud tedy píšete průchozí moduly, vnější závislosti jsou tak silné, že můžete od modulu abstrahovat a musíte se spíše zabývat vztahy mezi moduly, které propojuje, než průchozím modulem samotným. Modul degraduje na komunikační kanál, takže vás přestane zajímat co s informací dělá, ale zda je průchozí. A tak k němu budete přistupovat i při testování.
Výhoda modulu se pak ztrácí, protože mu intuitivně dáváte menší váhu a snadněji přehlédnete jeho špatnou funkci, ve své hlavě ho nahradíte abstrakcí, která vám zastře jeho reálné chování a stane se to zdrojem těžko odhalitelných chyb.
Imutable objekty v FP je vlastně taky snaha o lokalizaci informací a de facto modularizaci výpočtu, nikoliv programu jako takového. Funkce během výpočtu nekomunikuje s okolím, mění stav jen lokálně, pozorování okolí skrze jiné funkce během výpočtu není komunikace, protože to nemění stav jiných probíhajících výpočtů.