どの様な話？
プログラミングの手法は、すべて、
- 出来る中で、なにかを制限する
のだと思います。
制御の反転 Wikipedia 日本語版 の記事冒頭の最も目立つ所に、
- 「呼び出す側」と「呼び出される側」が、従来のプログラムとは逆になるようにする
と有りますが、これは建前であって、実際には、記事の目立たない、中の方に、まぎれる様に書かれた、
- 実行中のプログラムでオブジェクトどうしを相互に結び付け合うためには、結び付けられるオブジェクトどうしが互換性のあるインターフェースを持っていなければならない。
というのが本当の制限だと思います。
100%、インターフェースの変化をさせず、それにより、恩恵が有る、という事だと思います。
オブジェクト指向におけるインターフェースの制限
オブジェクト指向のクラスは、トレイトとかと違い、制限がキツイです。
関数（メソッド）がどこかのクラスに属する必要が有ります。これは、
- 出来る中で、なにかを制限する
という、プログラミングの手法に適っています。なぜ、この様な制限をしないといけないのでしょうか？
それは、
- 基本的にインターフェースの変化を否定しないので、
- 100%、インターフェースの変化をさせない様な制限で無い、
- 別の制限が必要
となったからだと思います。
従来の制御
制御の反転 Wikipedia 日本語版 で、
- 「呼び出す側」と「呼び出される側」が、従来のプログラムとは逆になるようにする
と有るので、
- 制御の反転 の逆を、
- 従来の制御
と言う事にします。
前に、「何を飛ばしていたのか？ １」で（我ながら厚顔無恥だったと、今になって思っていますが）、
すなわち、束因果ダイアログで言う、
- 「分岐」は、
- 何で思いつくのか？（設計段階）
で、
- 「合流」は、
- 何で自動で動くのか？（運用を考慮した実装段階）
と書きましたが、
これらは、従来の制御について、忠実に記述出来る枠組みだとおもいます。
「分岐」の効能
（インターフェースの変化を必ずしも否定しない）オブジェクト指向の、
- どこかのクラスに属する必要が有る
という制約は、「分岐」に由来すると思います。
すなわち、
- 勝手な原因を生やして、
- 勝手な結果（プログラム）を作ってはならない
という事を、
- どこかのクラスに属する必要が有る
という制限で実現するのです。
また、これにより、「思いつく」というのが、
- 他の人（上位者）から教わって、
- そこのみから、下位の（細分化された）原因を思いつく
という定型的な作業に落とし込む事が可能になるという利点も出ます。
「合流」の効能
制御の反転 Wikipedia 日本語版 の文中、
- シェルのコマンドで実行される古典的なアプリケーションではメインループが最上位で動いており、そこからライブラリなどのAPIを呼ぶのに対し、
と有りますが、
「合流」というのは、
- 複数のプログラムの部分を、
- 上位の呼ぶ側のプログラムを新規に作る事で、
- まとめる
事になると思います。まさに、「なんで自動で動くのか」を体現するのです。
時間発展に伴い、呼ぶ側のプログラムが変化する（インターフェースの変化も許容）のです。
これこそ、誰にも恥いる事なく提示できる「高階」の操作だと思います。
インターフェースの変化を100%させない「高階」など、"しているふり"に過ぎないと思います。
結論
これからも「インターフェースの変化をどう制限するか？」が不詳な状況でプログラミングが嫌いになる人は存在し続けることでしょう。
