大学生というインターフェースをはずさないか

たしか、大学生というインターフェースは、今は@Deprecatedされている。つまり今のバージョンのJVMでは推奨されていないとおもうんだ。
昔のJVMで大学生インタフェースが幅をきかせていた要因には、どんなインスタンスでもGC（ガベッジコレクション）されないという本来あり得ない設計だったことがその理由だと、昔のプログラマに聞いたことがある。でも、日本経済というハードウェアの構造が変わって、いまは、ガベッジコレクションが頻繁に行われている。呼び出されなくなった、無用なオブジェクトはヒープの無駄だそうだ。なんか切ないけど。

大学生インターフェースはpublicなnebou()メソッドとか、内部でprivateなnidone()メソッドとかもってるけど、どちらかというと、ほとんどは全体の処理スピードを低下させるメソッドなんだ。ちなみに、ikkinomi()メソッドも昔はよく呼び出されていたけど、まれにオブジェクトが突然死するという理由から、使ってはいけないメソッドになったんだ。

何より恐ろしいのは、大学生インターフェースをimplementsしていると、3年が経とうとする頃に、本人の意思とは無関係にshukatsu()メソッドがタイマーで発動して、RecruteSetへ半強制的にadd()されてしまうことなんだ。このSetは恐ろしい。add()されると、内部では大学生インターフェースであることを忘れて、単なるObjectとして扱われるんだ。もちろん、toString()はObjectに実装されてる自己紹介のためのメソッドだから、何か文字列を吐き出すことは出来る。でも、大学生インターフェースをimplementsしている間は、toString()を特定の形式にオーバライドしなきゃいけないと、みんな思っている。そもそも、大学生インターフェースは、まず自分の所属大学の偏差値に基づいて、他のクラスとの比較のために、equles(Daigakusei daigakusei)の結果を返すと思いこんでいる。その結果、toString()でも、その値にもとづく説明をまず返す用になってしまうんだ。例えば「自分は○○大学生です。」みたいに。呼び出し側は案外そんなことはどうでも好かったりするのだが。（ちなみに、このequles()はComparableインターフェース。つまり、それを実装したクラスは比較可能つまり序列がある。）そして、次は大学生インターフェースが持つ学部や履修した授業に関する情報と、サークルとか、バイトに関する課外活動についての情報を返すんだ。面白くないことに、ほとんどの大学生インタフェースを実装したクラスは、似たようなtoString()を返すんだな。そんなtoString()でも、たくさん情報があるうちはまだよかったんだけど、大学生インターフェースを取り除いて、単なるObject.toString()の結果は貧困になってしまう場合が好くある。最悪の場合、メモリ番地しか返さなくなってしまうんだ。それだけでは、どんなオブジェクトなのかさっぱりわからないって。

そもそも、RecruteSetはタイプセーフではない。toArray()で配列として戻される時には、大半の場合、社会人インターフェースを自動的に実装しているという変わった性質がある。面白いことに、社会人インターフェースを一度実装してしまうと、大学生インターフェースの時の属性なんてほとんどの人が忘れてしまうか、どうでもいいことになってしまう。そんな一時的なインタフェースによって、自分自身の自己紹介であるtoString()の出力の大半が占められてしまうのは寂しいと思わないか？

もちろん、今のJVMでは非推奨になってしまっているが、大学生インターフェースは、勉強が好きなオブジェクトにとっては便利であることは間違いない。正しく使えば、useLibrary(),とか、hasQuestion()とか、より上位の学生インターフェースをもつ複数のインタフェースの中でも、最も高機能なインターフェースとして、存分に活用することが出来るのだが。残念ながら、gakuwari()という例外を除くと、大学生インターフェースのメソッドの多くは忘れ去られているようだ。もっとjavadocを活用して、本来の設計意図をよく理解して欲しい。例えば、社会人インターフェースになると、readShinBun(ShinBunInputStrem shinbunInputSteam)はよく呼びだされるけど、大学生だとあまり活用されないのは残念。もちろん、大学生インタフェースでも持っているメソッドですよ。

そもそも、大学生インターフェースを実装しているフツーのクラスは、保有しているInputSteamクラスが少ないというのが大きな欠点なんだ。ShinbunInputStreamだけじゃなくて、もっと上位のSocialInputSteamクラスをぜひ活用して欲しいものだ。大学生インターフェースを実装するかどうかの若いオブジェクトはいろいろ視野を広げて、自分が将来どんなインターフェースを実装し、あるいは継承に頼らず、全くユニークなクラスになろうとするなどのチャレンジが許されているんだ。その可能性と視野を広げるのがInputStreamクラスなんだから、もって持ちすぎることはない。いろいろな入力を持って欲しい。最近のRSSreaderInputStreamも情報系の若者なら是非使うべきだとおもうし。

とまあ、そんなわけで最近のJVMの変化に合わせた、インターフェースの活用法について説教したけど、結局はどんなオブジェクトになろうとするかが、最大の問題なんだ。なので、あまり特定のインターフェースに依存するのはあまりおすすめしない。まして、自分自身のスーパークラスがあるなんて思わない方がいい。時代は常に変わって、スーパークラスの設計も変わるんだから。