ContractInterface

規約ベースのインターフェースって良しあしなのかな…と。
僕としては、「契約」として明文化されたinterfaceが好きなので、
規約で、決められた名前のメソッド…みたいなのは、若干違和感があるのです。

っつうかね、リフレクションAPIをガリガリに使ってるコード読んで、
その規約を読み取れとか、基本的に無理じゃね？とか。
そうすると、充実したドキュメントが必要になる訳で。
いや、まぁ、僕がドキュメント書くのが好きじゃないっつうか、嫌いって事は、
ここでは敢えて否定しないですよ。
乱暴な言い方だけど、ソースコードがドキュメントだ。みたいな。
そうは言っても、コードの一部分だけ読めば事足りるんなら、それはそれでえーやん…とか。
つまり言い換えると、ソースコードの全部がドキュメントって訳じゃなくて、
API的コードと内部処理ってある訳で。そうあれ、publicAPIとpublishAPIみたいな、アレ。
少なくともpublishedな所だけ、しかもそんなに難しくないんだったら、コード読んで貰ってもエエんじゃないか。と。
辛い日本語読むのと楽しいコード読むのとコスト的にあんま変わんなくね？とか、言ってるから変人なのか…。

翻って規約ベースのインターフェースは、メソッド名覚えて好きな奴だけ実装すれば、
それはそれで動くってのは、凄く便利なのはまぁ、便利。否定出来ない。
でも、この便利さって結局、規約を守る側の人にとって面倒か、そうでないかって話なんじゃね？と。
そうすると、そもそもJavaのinterfaceは、定義されているメソッド全部実装しないとエラーになるから、
空実装を持ったabstractクラスを作っちゃったりするけど、
そこがJavaの足りない所じゃねぇかと。
と言うわけで、こんなアノテーションを妄想してみた。

public interface Hoge {

    public void fuga();

    @Maybe({0})
    public int piro();
}

@Maybeでアノテートされたintefaceは、実装してもしなくても良いってのは、どうかな…とか。
実装クラスで、@Maybeなメソッドを実装しないと、コンパイラが勝手に空実装を埋めてくれる訳。
んで、valueに値を指定すれば固定値を返してくれる…とかね。