クラスと属性は恣意的に選ばれる

"人間"クラスが定義されているとして、俺というインスタンスは30歳で男性の"人間"と解釈できるが、一方で"30歳男性人間"とも解釈はできる。つまり、以下の2通りの文章はどちらも正しい。

• katzchang is a 30 years old and male human.
• katzchang is a human of 30 years old and male.

俺というインスタンスには子供がいるが、子供を持った30歳で男性の"人間"とも解釈できるが、"30歳男性子持ち人間"とも解釈できる。

• katzchang is a 30 years old and male and parent human.
• katzchang is a human of 30 years old and male having a child.

属性はクラスのより細かい解釈でしかなく、逆にクラスは属性の解釈の一つでしかない。

ちょっと抽象的な話から始めたけど、業務システム設計の場面でもかなり迷うことがある。例えば、ある権限のユーザをクラスで分けるべきか、属性で分けるべきか。

大抵、権限は能力と考えて、"Angela has authority of administration" と解釈すると思う。けど、"Angela is a administrator" と書くと、権限はユーザのサブクラスとも解釈できるでしょ。"Angela has a authority of the Administrator" なんて解釈もあることを考えると、もうどうしようもない。Administratorは静的な実体のないクラス？定冠詞があるってことはインスタンス？抽象的なインスタンス？とか。

この辺が、思考のフレームワークとしてのクラスベースオブジェクト指向の限界であって、即ちクラスベースオブジェクト指向言語の限界なんだろうと思う。このフレームワークにどうやって「その業務」を突っ込むか勝負。

って、手続き型な思考の方が「その業務」にマッチすることも多いんだよなぁ…。その場合、オブジェクト指向設計に当てはめるよりも「データ」と「手続き」に着目して設計した方が素直になるし、それを素直に実装する方が、わかりやすさっていう点で勝るような気もする。