セカイノカタチスマートフォン用の表示で見るセカイノカタチ世界のカタチを探求するブログ。関数型言語に興味があり、HaskellやScalaを勉強中。qtamaki.hatenablog.com先日、組織やプロジェクトの運営におけるコミニュケーションパスの問題について書きました。同じような問題が、プログラミングにおいても言えます*1。プログラムにおける変数や関数、クラスやメソッドなどのオブジェクト*2をノードとして見ると、それらにアクセスするという行為は、コミュニケーションを取っているのと同じです。下の図のように、プログラムとは、様々なノードとノード間のコミュニケーションパスの塊とみなすことができるのです。変数や関数をグローバルに参照するとすぐにスパゲッティ化するのは、コミニュケーションパスの本数が爆発的に増加することも原因となっています。会社やプロジェクトなどの組織の場合、せいぜい数百個程度のノードを相手にすれば良い話ですが(それでも問題ですが)、プログラミングの場合、数千や数万のノードがひしめき合うことになります。なんの対処もせずにプログラムを書くと、絶望的なほどにコミュニケーションパスが増大し、手に負えないほどに複雑化してしまうことになるのです。プログラムの複雑さは、コミニュケーションパスの量に比例します。逆に言うと、コミニュケーションパスを減らすことができれば、ソフトウェアの複雑化を抑えることができるということです。コミュニケーションパスの量を量ることで、ソフトウェアの複雑さを数値化することができ、より良い進化の方向性について、定量的に判断することができるようになるのです。コミニュケーションパスの性質コミニュケーションパスとは、お互いにやりとりしあう可能性のあるノード同士を結ぶ線のことです。2」で本数を計算することが出来ます。試しのノード数2000までのコミュニケーションパスの増加をグラフにしてみます。2000ノードの時のコミュニケーションパスの本数が1999000本となっており、相当「ヤバイ」感じがします。(^^;ただし、増加数の増加(つまり微分)は、だんだん1に近づくようで、最初急峻に立ち上がりながら大きな数になると伸び率が1倍に近づいて安定するようです。いえ、2000ノードの時点で約1000倍、10000ノードの時は49995000本と約5000倍となっていますので、単純な線形の伸びよりは遥かに増加率が大きいのですが・・・ジワジワ来る感じですね。「〇〇機能を追加しよう。「いやいや、これ以上オプション増やしたらヤバイっす。制御しきれなくなるほどではない気もするし・・・。うーん」みたいな、「真綿で首を絞めるように苦しくなっていく」という現実に則した数字なんじゃないかと、妙な納得感がありますね。(^^;アプローチコミュニケーションパスの増加を押さえるための手段を大まかに分けるとこのような感じになります。ノードを減らすノードをグループ化するノード間の通信を減らすそれぞれのアプローチについて説明します。ノードを減らすノードを減らすというのは、共通処理をまとめるところから始まって、クラスの継承やインターフェースを利用して、関数や変数の数を単純に減らすという方法です。単純ですが、問題に真っ向から立ち向かっており、効果も期待できます。別のエントリーでも書きましたが、処理の抽象化というのは、難しい作業となります。オブジェクト指向プログラミング言語では、クラスの継承やインターフェースを使用します。クラスを分割し役割分担することで、担当する役割の処理を複数のクラスに書かなくてもいいようにするなど、色々なテクニックを駆使してDRYを実現します。関数型プログラミング言語では、型クラスや代数的データ型を利用して、膨大な数のケースの組み合わせをシンプルに抽象化し、必要に応じて自由に組み合わせて計算をします。この基板の上に、高階関数やモナドなどの仕組みが乗り、高度な抽象化を実現しています。ノードをグループ化するノードを分割することによって、コミュニケーションパスの本数は劇的に少なくなります。オブジェクト指向プログラミング言語では、モジュール化であったり、ローカルスコープやクラスによるカプセル化が相当します。クラスによるカプセル化は、クラス自体が巨大になると効果が薄れるという問題があります。そのため、クラスに持たせる機能はなるべく単機能でシンプルにして、クラスとクラスの関係性によって処理を記述していくというのは、オブジェクト指向プログラミングの特徴的な方法論となります。クラスが増えていくとクラス間のコミュニケーションパスが増加する事になるため、ここのバランスが難しいところです。特定のクラスを多数のクラスが参照している状態では、グローバル変数と同じ問題が発生する可能性があります。ノード間の通信を減らすノード間の通信を減らすというのは、変数をイミュータブルにすることによって、読み取り専用としたり、関数の副作用をなくしていくアプローチです。これは主に関数型言語を用いたプログラミングの際に良しとされる特徴です。変数の変更は、それを参照する(=スコープに入っている)処理に影響を与えます。これは、間接的にスコープ内の処理通しがコミュニケーションパスを発生させることを意味します。変更の発生しないオブジェクトや変数は、読み取り専用となるわけですが、この場合間接的なコミュニケーションは発生しないため、コミュニケーションパスの増加が抑えられます。言語のサポートがあるかは別として、イミュータブルパターンは、どんなプログラミングスタイルでも有効なので、みんなせっせと取り組んでいます。全体的に関数型プログラミングの方向に誘導されつつありますが、関数の参照透明性とは、関数に渡した引数が戻り値以外の副作用を発生させない事を指します。参照透明性のある関数を組み合わせてプログラミングすると、出来上がったプログラムは、きれいなツリー構造になります。セカイノカタチの時に示したコミュニケーションパスを最小化する3つの基本的な形に即しています。プログラムは、この形を保っている以上、コミュニケーションパスを最小化することができるということです。ここにミュータブルなオブジェクトやグローバル変数、外部とのIOなどの副作用が加わると、間接的なコミュニケーションにより、あっという間にプログラムが複雑化してしまいます。まとめノードを減らすというのは、プログラムを抽象化していく作業です。どのプログラミングパラダイムでも、それぞれのアプローチで色々な機能がサポートされています。高度なテクニックを用いて抽象化されたプログラムは、シンプルに対象物を最小限の複雑さで構成することが出来ます。その代わりプログラムは難しくなります。(^^;ノードをグループ化するというアプローチは、主にオブジェクト指向プログラミングが得意とする手法です。クラスやパッケージに分割していって、カプセル化することによってノードの結合を分割することができるのです。関数型プログラミング言語は、ノードをツリー状に構成することによって、コミュニケーションパスを最小化しようとしています。コミュニケーションパスの観点から見た時に、オブジェクト指向プログラミングのアプローチは、その最小化に目標が定まっていないように見えるため、十分に正しいとは言えないのかもしれません。ノード間の通信を減らすという観点は、オブジェクト指向プログラミングにあまり見られなかった観点です。参照透明性を確保することにより、プログラムは、ツリー構成となります。コミュニケーションパスは最小限になり、影響しあうノードを劇的に減らすことが可能です。コミュニケーションパスの最小化という観点で両者を比較した場合、関数型プログラミングのアプローチのほうが優れています。いうか、偶然だと思いますが、関数型プログラミング言語は、コミュニケーションパスの最小化を真っ直ぐに目指しています。これは、方向性としては非常に正しく、プログラミングの一つの到達点なんだと思います。参照透明性は、オブジェクト指向プログラミング言語でも実現可能なことですので、どちらのパラダイムでも積極的に目指して行けたらいいなと思いました。おまけこちらの記事はマーブルワーズを使って検討しました。複雑に絡まった問題を効率的に検討、整理することが出来てとても便利です。2015(Qiita版)14日目の記事です。はてなブログProシステム開発の世界で15年の山の民による、世界のカタチを探求するブログ。(4)はてなブログをはじめよう!qtamakiさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。