最近は会社ブログしか書いてません。...、ある程度Javaに触れて来た人は必ず見たことがあるインターフェイスだと思う。私も何度も見てきたし、必要に迫られて自分の作ったクラスにSerializableをつけたこともある。こいつは一体何なのか?継承の便利さ僕らがまだJava初心者だった頃。継承というメカニズムに助けられながら育って来た。簡単に言えば、HttpServletクラスを継承しさえすれば、自分の作ったクラスがサーブレットとして認識されるのだ。abstractメソッドなどという便利な機能もあり、継承にあたって実装しなければいけないメソッドは確実に指示され、言われた通りにそのメソッドを実装すれば良い。StrutsのActionも然り。多くの場合は「継承さえすれば、望む物がだいたい出来上がる」というのがJavaの世界だと思っていた。世の中そんなに甘くないそう、ここで出てくるのは、俺の好きな「リスコフの置換原則」って奴です。「派生型は、基本型と置換可能でなければなりません。」...抽象的で分かりづらいですね。わかりやすく具体的にしていきましょう。以下のようなメソッドがあったとします。LinkedListなど、いずれを渡しても正常に動作しなければならない、という原則です。fooを実装する際、どんなリストなのかに関わらず、ひとまずListのルールに従ったもの(つまりListを継承した何らかのインスタンス)であれば動くように作れば良いのです。ここまではある程度簡単ですね。逆に、Listを継承した独自のMyListクラスを作る場合、どうなるでしょう。List型の引数というのは、さっき自分が作ったfoo()以外にも、あちこちで数え切れないほど使われています。MyListクラスは、世の中に存在するList型を引数に持つ全てのメソッドに対して使用可能(正常に動作)でなければならないのです。見たことも聞いたこともないメソッドでも正常に動作することを保証する、なんて出来るんでしょうか。普通に考えたらムリです。一つ前提を作ることによって、それが可能になります。「世の中に存在するList型を引数に持つ全てのメソッドは、Listインターフェイスの仕様(Javadoc)を前提に作られている」この前提があると「MyListはListの仕様に従っていれば問題ない」ということになります。やろうと思えば、size()メソッドで負数を返したり、get(100)の時にIllegalArgumentExceptionを投げるようなMyListだって書く事ができるんですね。以下の状況はありえないでしょうか。size()に-1を返すようなMyListを下記のbarメソッドに渡したら、無限ループですね。barは悪くないです。List#size()のJavadocを見ると(暗黙的にですが)負数を返すような記述は書かれていないから、負数は返ってこないという前提でコードを書いて良いのです。}}あーー、だいぶ話が逸れました。要するに、継承さえすれば仕様的に完全なものが作れる訳ではない。継承だけして安心すんな、って話です。クラスを継承したら責任も継承するんです。基底クラスが持っている責任(size()は個数を返さなければならん等)を、派生クラスでも果たさなきゃならんのです。Serializableにはどんな責任が...?やっと戻って来れた。単語の意味から紐解いてゆこう。Serializable。「Serialize可能な何か」という意味らしい。(シリアライズとは何か?については後ほど突き詰めます)RunnableはRunする能力、つまりこいつを実装するとスレッドとして走らせることができるようになった。Comparableは比較する能力、つまりこいつを実装すると相互に比較できるように(つまり、ソートできるように)なった...。継承だけして安心してるパターンの人たちにはなんと嬉しいことか。おめでたいとは正にこのことです。ご存知の通り、Serializableにはメソッドの定義が1つもない、いわゆる「マーカインターフェイス」という奴らしいです。...んなわけあるかぃw逆です。「このクラスはSerializableインターフェイスが持つ責任を引き受けます。SerializableのJavadocに書いてある通りの挙動を保証します。」っていう宣言をしたことになるんです。「じぶん、シリアライズできまっせ。