雑記帳または /dev/null

ソフトウェア開発、哲学、プログラミング、その他雑多なものもののメモ

メモ - 非意味的切断と依存性管理・疎結合

考察 哲学

思弁的実在論と現代について――千葉雅也対談集

思弁的実在論と現代について――千葉雅也対談集

Amazon

私は『動きすぎてはいけない』で、「接続過剰から非意味的切断へ」というテーマを掲げました。自分と他者の間にあまりにも多い関係性、そして、そこに生じるあまりにも多い責任を想定すると、我々は何もできなくなる。というのは、何か行為をするにあたって考慮すべきパラメータが無限化し、行為に移れないからです。 (...) 他者のための行為、利他的な行為の条件は、行為する自分が存在すること = 他者への関係性をある程度は切断すること、なのです。 (...) あくまでも接続が前提の上で、かろうじて切断する、という話なのです。

『思弁的実在論と現代について』 p.16-17

関係性の肥大とそこから生じる多数の責任によって、考慮すべきパラメータが爆発し、結果何もできなくなる。 それを回避して、他者のために何か行為することを可能とするためには、関係性をある程度は切断することが必要になる。

ソフトウェアの文脈ではモジュール間の依存性の管理と疎結合が重視されるが、それらについて、この「接続過剰から非意味的切断へ」というテーマを応用できないか。

一つに、モジュールが相互に関連しあうと、一つのモジュールを変更したときの影響範囲が直接的・間接的に広がっていく危険が生じる。 よって、モジュール間の関係性を間接的にして影響範囲を狭めたり1、それを単方向にして循環させないようにしたり2といったテクニックないし原則が提唱されている。 しかし、これによってモジュール間が全く「無関係」にされたわけではなく、あくまでそれらは間接的にせよ接続し続けており、かつそうした依存関係の管理は、あくまでそれぞれのモジュールが「他者」としての他モジュールのため十全に「機能 = 行為」できるようにするための処置である。 これは、ソフトウェア上におけるモジュール間の「非意味的切断」とは考えられないか。

また、あるモジュールとモジュールが密接に関連しあった場合、それこそ互いの内部構造やその処理機構なども相互に承知したようなレベルでの密結合に陥った場合、両者は互いに相手に対して大きな責任を想定し、また実際に負う必要が生じる。その多大な責任によって、絡み合った両者のモジュールは「考慮すべきパラメータが無限化し、行為に移れない」という結果に至る。そこまでは至らずとも、他モジュールへの依存が強いほど、換言すれば他モジュールとの関係性が強く多様なほど、程度の差はあれ、「考慮すべきパラメータが無限化し、行為に移れない」という結果へと近づいていく。

そのような結果を回避するためにあるいは遠ざかるために、部分的な関係性に限定すること依存の程度を減らしたり3、依存する対象をより抽象化されたモジュールに規定することで関係性を弱めたり4、といったアプローチも存在する。 これらもまた、これは、ソフトウェア上におけるモジュール間の「非意味的切断」として、それも「接続が前提の上で、 かろうじて 切断」しようとする試みとは考えられないか。疎結合とは、完全な「切断」ではなく、あくまで緩やかに繋がりながら、その上でなおその関係性を「ある程度は切断する」試みである、と。

  1. Principles and Patterns - The Open Closed Principle↩

  2. Principles and Patterns - The Acyclic Dependencies Principle↩

  3. Principles and Patterns - The Interface Segregation Principle↩

  4. Principles and Patterns - The Stable Abstractions Principle↩

メモ - 「わかりやすい」「わかりにくい」考1

考察

奇妙な用法

任意の対象Xについて、私達はしばしば「Xはわかりやすい」「Xはわかりにくい」と語り、また実際にそう認識する。 この認識は、素朴にはXについての認識であり、またXの性質について語ったものとして捉えられているように思う。

しかしながら、「Xはわかりやすい」「Xはわかりにくい」という認識がXについての認識、またXの性質について語ったものだとすると、 これらにいくつか奇妙な用法が存在している。

「Xがわかりにくくて、理解できなかった」

難解なテキストや説明に直面したとき、しばしば見聞きする用法である。 これは専ら、対象のX(というテキストや説明)が用いている表現や記述について、批判的に語る文脈で用いられる。

あるテキストや説明について、それが「わかりにくくて理解できなかった」、言い換えれば「理解に努力や困難を伴った」あるいは「理解できなかった」という場合、それには二つの原因が考えられる。

  • そのテキストや説明が語る意味内容を理解するだけの前提知識・理解能力が読み手に欠如ないし不足しているため
  • そのテキストや説明が語る意味内容に対して、そのテキストが採用している表現・記述方法が不適当であるため

「Xはわかりにくい」という用法は、もっぱら後者を主張するために使われる。

「Xがわかりにくくて、理解できなかった」という用法の奇妙な点は、「Xの内容を理解していないにも関わらず、Xはわかりにくい表現・記述を用いていると評価している」という点である。 というのも、あるテキストや説明が語る意味内容に対してそのテキストや説明が用いている表現・記述方法が不適当であるかどうかは、本来そのテキストや説明が語ろうとしている意味内容を理解していなければ不可能だからである。

Xの説明として表現・記述方法が不適当であるというためには、Xの意味内容に対してその表現・記述方法が冗長である、Xの意味内容に対してその表現・記述方法が対応していない、Xの意味内容に対して矛盾を含むなど、なにかしらXの意味内容と実際に用いられている表現・記述方法を比較して初めて可能だからだ。 一見して冗長に見えたとしても、表現・記述方法が対応していないように見えたとしても、矛盾を含むように見えたとしても、現にそれらが冗長であり非対応であり矛盾であるかどうかは、それがXの意味内容に対してまさにそのようであることが確認される必要があり、そのためにはXの意味内容を理解する必要がある。さもなくば、自身の能力不足・欠如に由来する理解の困難さを、Xの形質に由来するものとして取り違えかねない。

にも関わらず、私達は掲題したような用法を使うことができるし、実際に掲題のような認識を抱くこともできる。 Xを理解していない状態で、すなわちXの「わかりにくさ」を認識するための比較対象を持たない状態で、私達は「Xがわかりにくい」ということをどうやって、何を材料に認識したのだろうか。

「Xがわかりやすい」と語った後で、「Xが実際にはわかっていなかった」と語る

私達は時折、Xについてのテキストや説明や図を見て「これはわかりやすい」と語り、またそのように認識することがある。 しかし、その後で何らかをきっかけに「Xがわかったと思っていたが、実際にはわかっていなかった」と語り、またそのように認識することがある。

この用法において奇妙な点は、「わかっていなかった」と後で認識されるということは、すなわち「Xはわかりやすい」と認識した時点でも「わかっていなかった」のだが、では「Xはわかりやすい」と語り認識したそのとき、私達は何について「わかりやすい」と語っていたのだろう、という点だ。

「Xはわかりやすい」と語ること、およびそう認識することもまた、「Xはわかりにくい」と同種の構造と制約を持つ。すなわち、「Xはわかりやすい」と語るためには、本来Xの意味内容と実際にXが採用した表現・記述形式との間に冗長さや非対応や矛盾が無いということが、Xの意味内容と実際の表現・記述形式を比較することによって認識される必要があるはずだ。 しかしながら、「Xはわかりやすい」の後での「Xが実際にはわかっていなかった」と語ることは、実際には「Xはわかりやすい」と語った時点でXについて「わかっていなかった」ということになる。 では、最初に「Xはわかりやすい」と語ったとき、私達は一体Xの何とその表現・記述形式を比較したのだろうか。

「わかりやすさ」「わかりにくさ」はどこに帰属するか

「わかりやすさ」「わかりにくさ」は、一般に「Xはわかりやすい」「Xはわかりにくい」といった形式で用いられる。 これは一見してXが持つ性質ないし特徴について語っているようにも見え、また、実際Xの性質ないし特徴について語るために用いられることもある。

しかし一方で、同一のXについてそれを「わかりやすい」と認識するか「わかりにくい」と認識するかは、必ずしも一致しない。その不一致は、は異なる人物の間においてだけでなく、異なる時刻の同一人物においても発生する。この認識の差異は何に由来するのか。その差異には少なくともXを観測し認識する人間の主観が関わってくることは、「Xはわかりやすい」「Xはわかりにくい」と認識する主体が個々の人間である以上、疑う余地は無いだろう。問題は、その主観がどのように関わってくるかだ。

note: フッサール、現象学、超越と内在、間主観性、カント、超越論的観念論

「わかりやすい」「わかりにくい」は全く主観にのみ由来するものであり、Xには帰属しない

すなわち、主観は「わかりやすい」「わかりにくい」という認識に対する全くの発生源であり、それ以外にこれらの認識の材料となりうるものは存在しないとする場合。 もっともらしく思われるが、一方で、「わかりやすい」「わかりにくい」が主観のみを由来するとするなら、なぜ私達は「わかりやすさ」「わかりにくさ」がXに由来するかのように語り、またそのように認識できるのだろうか。 「わかりやすい」「わかりにくい」が全くの主観に由来するとして、では「わかりやすい」「わかりにくい」を構成する主観はどのようなかたちをとり、また、どのような方法でそれらを実現させるのか。その主観の背後にある認識はどのようなものか。 「わかりやすい」「わかりにくい」が全くの主観に由来するのならば、複数の人間が共通して「わかりやすい」「わかりにくい」と評価する現象は、全くの偶然なのだろうか。そのように評価されるXには、そのような評価が発生する傾向を生み出すような性質は、一切存在しないのだろうか。また、これらの認識が全くの主観に由来するというのなら、「わかりやすい」「わかりにくい」について語ることを通じて何かを他者と共有する余地は存在するのだろうか。

「わかりやすい」「わかりにくい」は主観に由来する部分と対象に由来するもの、両方を持つ

すなわち、「わかりやすい」「わかりにくい」とは、個々人の主観と対象「それ自体」が持つ性質の混合によって生じるものであるとする場合。

まさに対象「それ自体」が持つ性質・特徴があり、それが「わかりやすい」「わかりにくい」という認識の材料として含まれるならば、複数の人間が共通して「わかりやすい」「わかりにくい」という認識を抱くのは、まさにその対象「それ自体」が持つ性質に由来するものと考えられるかもしれない。 しかし一方で、その一致が単なる偶然な認識の一致によらないという可能性は、どのようにして保証されるのか。 仮にそうした対象「それ自体」の特徴・性質があったとして、その性質はどのようにして分析されうるのか、あるいはそもそも分析可能なのか。換言すれば、「わかりやすい」「わかりにくい」という認識を構成する諸々の材料の内、どれが主観にのみ由来するもので、どれが「それ自体」の性質に由来するものか、それを分析して峻別できるのだろうか。「それ自体」の性質・特徴が認識の材料となることはあっても、「それ自体」の性質・特徴を認識し語ることはできるのだろうか。

次

philomagi.hatenadiary.jp

メモ - 「オブジェクト指向はすでに粒度が時代にあっていない 」について所感

ソフトウェア

元記事

https://nowokay.hatenablog.com/entry/2021/09/25/042831

本文について

  • 「オブジェクト指向」が多義的に使われているので、ここでは「オブジェクトを基本単位とするアプローチ」程度の意味で使っている模様

    • 基本的にはOMTの「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」 に従う

    • ↑ともあるが、特段この定義を踏まえた議論はしていない
  • 全体の論旨としては、オブジェクトという単位はもう不要(≠必須ではない)で、関数という単位さえあれば十分、という内容
    • その根拠として「部品の再利用が喧伝されたが、結局ごく部分的なものにとどまった」
    • 「必須ではない」ではなく「不要である」という主張なのは、以下から明らかと言って良いと思う
      • 冒頭で「オブジェクトdis」と宣言(定期的に書いてるというだけで、本文とは無関係とするのはムリがある)
      • 「もうソフトウェアの記述としてはオブジェクトという単位は大きすぎて、関数という単位で管理すれば十分」
    • 部品の再利用という面では、オブジェクトという単位ではなくWeb APIという単位で、すなわち「サービス」という単位での再利用が主流になっている
      • これをさらに進めて、ラムダやファンクションといった単位での配置も使われてきている

      • そうするともうソフトウェアの記述としてはオブジェクトという単位は大きすぎて、関数という単位で管理すれば十分ということにもなります。 ※1

    • 「え、いまどきオブジェクト指向でつくらなくない？」っていつも思います。 ※2

    • もし「オブジェクト指向」を勉強したいと思ったら、その知りたいことは実際にはソフトウェア工学という分野でまとまっているので、そういったタイトルの本を読むのがいいと思います。 ※3

所感

「再利用」という観点では確かにサービス(Web API)という単位での提供が主流だけれど、サービスの中身をどう作るかはまた別の話ではないか

  • なので、※1は端的に論理の飛躍。
  • 外部I/Fの単位が「サービス」になったからといって、その内部構造も「サービス」を基本単位とする必然性も必要性も無い。
  • その方が都合良ければそうすれば良いけど、そこから主張できるのは精々が「オブジェクト以外を単位にすることがあっても良いよね」程度で、「オブジェクトという単位は不要だよね」は飛躍。
    • 「オブジェクト以外を単位にすることが有っても良いよね」なら、特に異論は無い。
  • また、Web API や SOAを持ち出して語っていたのは「いかにしてソフトウェアを再利用するか」という話だったが、※1では「ソフトウェアの記述」にすり替わっている、あるいは飛躍している。
    • Web APIやSOAの隆盛がただちにその内部記述方法を規定するわけではないのは、↑のI/Fと内部構造の話と同じ。
    • 後述するが、 自身はソフトウェア記述においてオブジェクト指向のアプローチもオブジェクト単位の表現・記述も使っているし、そしてその恩恵も感じている
    • 大きすぎるオブジェクトや小さすぎるオブジェクトを作ってしまうことはあるが、それは単純に自分のしくじり。
      • 関数だったら大きすぎる関数や小さすぎる関数を作ることがありえなくなるわけでもなし。

※2は個人の感想としか言いようがない

  • 自分もWebサービス開発していて、そのI/Fは確かにAPI単位で提供してる。
  • しかしその内部ではオブジェクトを頻繁に使っているので、「そうなんですか、私はしょっちゅう使います」としか。

※3は検討の余地がありそうで、鵜呑みにするのは危険と思われる

「オブジェクト指向が流行ったときは、分析設計で出てきた要素をコーディングでもそのまま使えるというのが大きな宣伝文句でした」

  • この話について、挙げるだけ挙げてその後特に言及してない(次の段落で、すぐに部品再利用の話へ移ってしまっている)が、この点についてはどういう評価なのだろう
  • これは現代でも重要な要素だと思うし、オブジェクトという単位を用いるからこそ発揮できる優位性だと思っている
  • 「分析設計ででてきた要素をコーディングでも使う」という話と、「作った部品を他の場所でも再利用する」という話が、同種同列だと捉えられているのだろうか。
    • だとしたら、前者は意味的・概念的な再利用であるのに対して、後者は実装的・機能的な再利用であるにも関わらず、その差異を無視している。
    • Knuthが言うところの「アート」と「サイエンス」の内、「サイエンス」にしか目を向けずに語っているような雰囲気を感じる(感想)

問題領域と解決領域の関係について

考察

問題の形は解法のそれと必ずしも一致しない。 むしろ、問題の形は解法の形について、何も指示していない。 問題と解法の形が一致していないことは、必ずしも解法の不調和を意味しない。

では、解法から見た時はどうか。 解法は、「問題」なるものをどのように捉えたかを映し出す。 問題に基づいて解法が決定されるのではなく、むしろ解法が問題を定義する。

「1以上10以下の自然数の合計を求めよ」という問題について。 この問題の外観をそのままなぞれば、おそらく 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 = 55 という形になる。 これは「1以上10以下の自然数の合計」という問の形に、ほぼそのまま依存した形となっている。

これを、11 * 5 = 55 と解くこともできる。 「1以上10以下の自然数の合計」を (1 + 10) + (2 + 9) + (3 + 8) + (4 + 7) + (5 + 6) と整理してといたもの。 これは、「(A1 + An) + (A2 + An-1) + ... (An/2 + A(n/2 + 1))」の合計という形に問題を改変してしまっている。 掛け算による表記は、さらにそこから「和がnとなる自然数のペアの個数」という形にまで、跡形もないレベルでの改変を生じさせている。

「1以上10以下の自然数」を、「1 <= n <= 10、等差1の等差数列」と捉えれば（改変すれば）、シグマによる一般化した記述も可能となる。 この場合、もはや個々の数とその合計を示す計算式を記述する必要すらなくなる。

これらに共通しているのは、問題から解法が導かれるのではなく、むしろ問題について「このように解決できる」という認識から問題が改変されている様子だ。 問題によって解法が定まるのではなく、むしろ、解法が問題を定義しているのではないか。