Beyond Objects
本論文は、システムの機能をドメイン内の個体へと直接マッピングするというオブジェクト指向の核心的な原則は本質的に欠陥があり、断片化を招くものであると論じ、代わりにオブジェクト指向を放棄し、ドメイン内の個体を機能モジュールから切り離すアプローチを採用することを提案するものである。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
ダニエル・ジャクソンの論文「Beyond Objects（オブジェクトを超えて）」の解説です。分かりやすい言葉と比喩を用いて説明します。
大きなアイデア：「ワンサイズ・フィッツ・オール（万能型）」という間違い
あなたは家を建てているところだと想像してください。過去50年間、ソフトウェア構築における標準的なルールは、「家のすべての部屋は、そこに住んでいる人が管理しなければならない」というものでした。
ソフトウェアの世界では、これは**オブジェクト指向プログラミング（OOP）**と呼ばれます。もし現実世界に「ユーザー」が存在するなら、コードの中にも「ユーザー・オブジェクト」を作るという考え方です。そのオブジェクトは、そのユーザーに関するすべてのデータ（名前やパスワード）を持ち、かつ、そのユーザーに関連するすべての作業（ログイン、レビューの投稿、テーブルの予約など）を行うことになっています。
ダニエル・ジャクソンは、このルールは罠であると主張しています。一見論理的に聞こえますが、実際にはソフトウェアを複雑に絡まったメッシュ状にしてしまいます。彼は、すべての仕事を「人（オブジェクト）」の中に詰め込むのをやめ、誰がそれをするか（個人）ではなく、**何が起きているか（アクション）**によってソフトウェアを整理することを提案しています。
問題点：「スイス・アーミーナイフ」対「専門ツール」
ジャクソンは、すべての仕事を単一の「ユーザー・オブジェクト」に押し付けることが、主に2つの頭痛の種を引き起こすと述べています。
1. 「スイス・アーミーナイフ」問題（混同）
ユーザー・オブジェクトがスイス・アーミーナイフだと想像してください。そこには刃、ドライバー、コルク抜き、爪楊枝が付いています。
- 問題点： コルク抜き（ユーザーのパスワード処理）を使いたいだけでも、重いナイフ全体を持ち歩かなければなりません。もし刃の部分を変更したい（レビューシステムのバグを修正したい）場合、誤ってコルク抜きを壊してしまうかもしれません。
- ソフトウェアにおいて： 「ユーザー」オブジェクトは、ユーザーのパスワード、レビュー履歴、通知設定、そして予約ロジックのすべてを一つの巨大なファイルの中に保持することになります。レビューの仕組みを変更したいだけなのに、パスワードのコードまで掘り起こさなければならないのです。これは乱雑で、修正が困難です。
2. 「手が多すぎる」問題（断片化）
「テーブルを予約する」というタスクを考えてみましょう。
- 問題点： 誰がこれを行うべきでしょうか？ ユーザーでしょうか？ レストランでしょうか？ テーブルでしょうか？ それとも予約（Reservation）でしょうか？
- ソフトウェアにおいて： 「ジョブはオブジェクトに割り当てる」というルールがあるため、コードがバラバラに分割されてしまいます。「ユーザー」が予約を持っているか確認し、「レストラン」がテーブルが空いているか確認し、「予約」オブジェクトがチケットを作成します。
- 結果： 一つの予約を行うために、コンピュータは3人の異なる人物を3つの異なる部屋に走らせ、彼らに会話をさせなければなりません。もし一人がもう一人に伝え忘れたら、システムは壊れてしまいます。これは**断片化（Fragmentation）**と呼ばれます。
比喩：レストランの予約
ジャクソンはこの例を使って説明しています。
旧来のやり方（オブジェクト指向）：
「ユーザー」オブジェクトと「レストラン」オブジェクトがあります。
- アリスがテーブルを予約しようとすると、彼女の「ユーザー」オブジェクトに尋ねます。
- ユーザー・オブジェクトは、「レストラン」オブジェクトにテーブルが空いているか尋ねます。
- レストラン・オブジェクトは、「スロット（枠）」オブジェクトに尋ねます。
- そして「予約」オブジェクトが作成されます。
- 混乱： 「アリスは一度に2つのテーブルを予約できない」というルールに変更したい場合、ユーザー、レストラン、予約のすべてのオブジェクトを更新しなければなりません。これらはすべて絡み合っているからです。
新しいやり方（コンセプト）：
「誰が所有しているか？」と問う代わりに、「この一連のルールは何に関するものか？」と問いかけます。
ジャクソンは、ソフトウェアを**「コンセプト（概念）」によって整理することを提案しています。コンセプトとは、会社における「個人」ではなく、「専門チーム」や「部署」**のようなものだと考えてください。
- コンセプト1：「予約（Reserving）」
- このチームは、約束（コミットメント）に関するすべてのルールを扱います。ユーザーが誰であるかは気にしません。ただ「予約するという行為」にのみ焦лоうします。誰が何を予約したかのリストを保持します。
- コンセプト2：「空き状況（Availability）」
- このチームは、テーブルが開いているかを確認する「行為」を扱います。誰が予約しているかは気にせず、ただ「スロット（枠）」にのみ関心を持ちます。
- コンセプト3：「ユーザー認証（User Authentication）」
- このチームは、その人が本人であるかどうかを確認するだけです。
これらがどのように連携するか：
ユーザー・オブジェクトがレストラン・オブジェクトを呼び出すのではなく、これらの「コンセプト」は**「同期（Synchronization）」**（信号機のようなもの）を通じて対話します。
- ルール： 「リクエストが入ってきたとき、空き状況が『Yes』と言い、かつ認証が『進め』と言えば、予約ができる」
なぜこちらの方が優れているのか
- 絡まった結び目がない： 「予約」チームは、パスワードのチェック方法を知る必要はありません。「認証」チームは、テーブルの空き状況を知る必要もありません。これらは分離されています。
- 「誰が所有するか」の議論が不要： 「キャンセル」ボタンがユーザーに属するのか、予約に属するのかで争う必要はありません。予約の状態を管理する「コンセプト」の中に、単にキャンセル・ロジックを配置すればよいのです。
- より明確なマップ： コードを見たとき、誰が何のデータを持っているかという混乱したマップではなく、ビジネスルール（予約、空き状況）が明確に見えてきます。
「オブジェクト」と「コンセプト」の違い
- オブジェクト： あらゆるものになろうとする小さな機械（データ ＋ ロジック ＋ アイデンティティ）。それは、シェフであり、ウェイターであり、会計係でもあることを同時にこなそうとする人のようです。
- コンセプト： 特定の「仕事」や「関係性」を扱うモジュール。それは、専門化された部署のようなものです。「シェフ部門」は調理を扱い、「ウェイター部門」は配膳を扱います。彼らは連携しますが、一人の中に混ざり合うことはありません。
結論
ジャクソンは、すべてのソフトウェアを捨て去るべきだと言っているのではありません。オブジェクト指向プログラミングの核心的なルールである**「すべての仕事を、それが属する対象（人）に割り当てる」**という考え方が、問題の根源であると言っているのです。
**「コンセプト」へと切り替えることで、ソフトウェアを「人々の集まり」のように見せようとするのをやめることができます。代わりに、それを「ルールと関係性の集まり」**として整理します。これにより、コードは読みやすくなり、修正しやすくなり、何か小さな変更を加えたときにシステム全体が壊れるリスクを減らすことができるのです。
これは、より古くシンプルな考え方（リレーショナルデータベースのようなもの）への回帰ですが、現代のソフトウェアのニーズに合わせてアップデートされたものです。これにより、より脆弱性が低く、より論理的なシステムを構築することが可能になります。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。