オブジェクト指向で”涼宮ハルヒの憂鬱”

以前に読んで面白いなと思ったライトノベルだ。

シリーズ化されているものの表紙が常に美少女で三十路男には買い難いことこの上なかったのだが、話自体は驚くほどエロがなく、変わりにSF要素が強いので、ライトなのは間違いないが、なかなか楽しめた。

ま、とは言っても、続きも出ないし、あくまでも「前に読んだ」で終わっていたのだが、最近、Youtubeを見ていてたまたま、過去に部分的にアニメ化されたその続きが映画になるというのを知った。

見てみたい気がするが劇場に足を運ぶ勇気は出せそうにない…。

だからと言う訳ではないが、その映画化されるあたりの話に近いところのいくつかの事柄をJavaを想定してクラスとしてモデリングしてみた。UMLで書けばより良いのかも知れないが、正直ちゃんと知らないし、まあ面倒でもあるので、まあ書式は感覚的なもので。

とは言え…。

自分で言うのも何だが、俺はいったいなぜこんなことを書いたのかがわからない。もちろんネタと言えばネタなんだが、一般的に通じるとも思えず、マニア向けにもさほど面白いとも思えず。



より正直に言えば、ふとネタとして思いついた時は、５行程度でまとめる気分だったのだが、なんか育ってしまって、途中から自分でもバカだなと思いつつ、不思議と止められず…。

まあ。以下、そういうわけでのネタです。

　　　＊　　　＊　　　＊　　　

なんとなく”インターフェース”な長門をinterfaceとしたくなるが、同じポジションで少し仕様が違う朝倉などもいるので、ちょっと違う。


統合宇宙思念体
class DataOvermind
+ getInstance() : DataOvermind
- createDataEntity() :

これはまず間違いなくシングルトンモデルだろう。


統合宇宙思念体の対外インターフェース
interface DataOvermindCommunicator


対有機体コンタクト用ヒューマノイドインターフェース向けの実装
class DataEntityCore implements DataOvermindCommunicator //例　前期長門
class SequentialDataEntityCore implements DataOvermindCommunicator //例　後期長門


対有機体コンタクト用ヒューマノイドインターフェース(DataEntity)
class DataEntity
- DataOvermindCommunicator

DataEntityという訳語は英語のWikipediaから。

主流派
abstract class DominantDataEntity extends DataEntity

急進派
abstract class RadicalDataEntity extends DataEntity

enumで派閥を表しても良いのかも知れないが、DataEntityの派閥は生成後には変わらないようだし、振る舞いにも少し差があるのかなということで、サブクラスでタイプコードを表現してみた。

class Nagato extends DominantDataEntity

class Kimidori extends DominantDataEntity (?)

インスタンスではなくクラスが違うと思う。また長門のインスタンスが複数あるという考えはストーリーから察して受け入れ易くもある。下記の喜緑も。

class Asakura extends RadicalDataEntity

人間
abstract class Human
+ enableTPDD()

キョン
class Kyon extends Human

みくる
class Mikuru extends Human

TPDD
class TPDD

TPDDは一応コンポジションで持つ。enableでフラグが立つのかも知れないが、enableされる前はNULLなのかも知れないと。

----

ここで、キョンとみくるは本質的に同じだがenableTPDD()されたインスタンスか否かが違う。

問題なのは、「涼宮ハルヒの消失」の最後の場面では、KyonがDataOvermindCommunicatorインターフェース経由でアクセスという原則を超えて、DataOvermindを操作（圧力をかける）しようとしたこと。

これは、喩えれば、

class Kyon ... {
...
void claimFor(DataEntity dataEntity){
...
dataEntity.getDataOvermindCommunicator().sendMessage(message);
...
}
...
}

のようなことで、責務を超えてカプセル化の原則に背いているのではないか。


ただ、実際には直接通信したわけじゃないから、Kyonの上記コードは

dataEntity.relayToBoss(message);

で、DataEntity#relayToBoss(Message message)内部にて

this.dataOrvermindCommunicator.sendMessage(message);

になるのかも知れず、それならまあいいのか。とも。


ただいずれにしても、インターフェースの向こう、直接操作しているクラスの向こうに干渉しようとするのはクラス設計上は良くないはずなのだが、そういう「良くないこと」をするからドラマとして盛り上がるのである。

ただ、俺は自分の仕事で無駄にドラマ（とりわけ困難に関わる）を感じたくないから、良くなくない設計を目指さねばならない。