- PR -

アノテーションに @Override があるのに @Implements のようなものがないのはなぜ?

1
投票結果総投票数:7
あってもよい 3 42.86%
どっちでもよいがたまたまないだけ 3 42.86%
あったらダメ 1 14.29%
  • 投票は恣意的に行われます。統計的な調査と異なり、投票データの正確性や標本の代表性は保証されません。
  • 投票結果の正当性や公平性について、@ITは一切保証も関与もいたしません。
投稿者投稿内容
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷        良回答(20pt)
投稿日時: 2007-02-10 14:45
私は、Java の新機能に疎く、いまのところアノテーションというものがあるという知識であり、とりあえずコーディング時に @Override が付けられる場面では付けている、という程度なのですが、件名のような疑問を持っています。
たとえば、つぎのようなコードの場合、
コード:
interface Foo {
	
	void getStart();
}

public class Hoge implements Foo {

	@Implements
	public void getStart() {
	}

	public void getState() {
	}
}


というように @Implements (と仮に名付けた)というアノテーションを付けられたほうが便利だと思うのです。しかし、アノテーションには @Override はありますが、@Implements に相当するような機能はないようです。なぜないのでしょう?
これは、結局は interface と abstract class との違い、ということに帰結するのだろうと予想しています。これについては過去にもこの掲示板でいろいろ質問させていただきました。
しかし、@Implements がないという理由がやはり分かりません。あってもいいんじゃないかと思うんですが、どうでしょうか?
それともあったらダメなのでしょうか?(なにか破たんするようなことがあるのでしょうか?)
uk
ぬし
会議室デビュー日: 2003/05/20
投稿数: 1155
お住まい・勤務地: 東京都
投稿日時: 2007-02-10 15:57
アノテーションというのは、コンパイラへの指示あるいはヒントだと思うのですが、
そもそもimplementsキーワードで実装するインタフェースを示すことができるのに、
さらにアノテーションで明示する必要性はないと思うのですが。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷        良回答(20pt)
投稿日時: 2007-02-10 16:42
引用:

ukさんの書き込み (2007-02-10 15:57) より:
アノテーションというのは、コンパイラへの指示あるいはヒントだと思うのですが、
そもそもimplementsキーワードで実装するインタフェースを示すことができるのに、
さらにアノテーションで明示する必要性はないと思うのですが。


ありがとうございます。コンパイラーに対する指示、というのはあまり意識していませんでした。(ソースコードを読む)人に対する指示という面を意識していました。
ただ、アノテーションをあくまでもコンパイラーに対する指示だとすれば、
コード:
abstract class Foo {
	
	abstract void getStart();
}

public class Hoge extends Foo {

	@Override
	public void getStart() {
	}

	public void getState() {
	}
}


のように付けることができる @Override はなんのために存在するのか、という疑問が出てきます。
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2007-02-10 17:07
コード:
class Hoge{
    void test(){
         System.out.println("Hoge");
    }
}

class Piyo extends Hoge{
    @Override void test(){
         System.out.println("Piyo");
    }
}


というクラスがあったとします。
そしてHogeというクラスを以下のように修正したとします。
コード:
class Hoge{
    void test1(){
         System.out.println("Hoge");
    }
}


この場合、JDK1.4まではHogeは具象クラスなので、
Piyoもコンパイルエラーにはなりません。
しかし、@Overrideによってエラーとすることができます。

いまどきIDEで開発するでしょうし、
メソッド名の変更はリファクタリングを行うでしょうから、
存在意義は薄いといえます。

また@OverrideのRetentionがSOURCEなので、コンパイラが対応している必要もあります。
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2007-02-10 17:20
追記ですが、スーパークラスのメソッドの引数を変更する場合、
リファクタリングによる引数追加も可能ですが、
私の場合は直接修正してしまうことが多いです。
(わかっているのですが、極力やってはいけないことではあります)

なので、そういうケースでもエラーとさせれるので有効かもしれませんね。
お犬様
ベテラン
会議室デビュー日: 2003/01/26
投稿数: 67
投稿日時: 2007-02-10 19:35
@Override の役割に関してはかつのりさんが既に書いていらっしゃるとおりだと思います。

ちなみに、mustang からはコンパイラの挙動が変わって、implements なメソッドに @Override をつけてもコンパイルエラーにはならなくなったようです。

例えば、
コード:
interface I { void method(); }
class C implements I {  @Override public void method(){} }

は、tigerではエラーになるようですが、mustang ではエラーにならないようです。ただし、mustang でも依然として @Override のドキュメントは修正されていないままのようです。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷        良回答(20pt)
投稿日時: 2007-02-11 10:48
引用:

お犬様さんの書き込み (2007-02-10 19:35) より:
ちなみに、mustang からはコンパイラの挙動が変わって、implements なメソッドに @Override をつけてもコンパイルエラーにはならなくなったようです。


ありがとうございます。JDK 1.6.0 でコンパイルしてみましたが、おっしゃるとおりコンパイルできました。
(ちなみに、Eclipse 3.2.1 では、JDK Compliance の Compiler compliance level を 6.0 にしてもコンパイルエラーになりました。)

個人的な感想としては、キーワードは @Override と違うものにしてほしかったです。
今の JDK 1.6.0 の仕様だと、
・interface
・class の abstract なメソッド
・class の abstract ではないメソッド
のどれを実装する場合でも、キーワードは @Override ひとつですが、3通りのキーワードでそれぞれを区別できるようにしてほしかったです。

--
unibon {B73D0144-CD2A-11DA-8E06-0050DA15BC86}
1

スキルアップ/キャリアアップ(JOB@IT)