パターンの注釈を維持するプロジェクトはありますか?
たとえば、ビルダーを作成するときは、 でマークしたいと思い@Builderます。
このように注釈を付けると、コードが何を実装しているかがすぐに明確になります。また、@Builderアノテーションの Javadoc は、ビルダー パターンの説明を参照できます。さらに、ビルダー実装の Javadoc から Javadoc への移動は、 で注釈を付けると@Builder簡単になります。@Builder@Documented
コード内にあるパターンやイディオムに対するこのような注釈の小さなセットの蓄積が遅くなりましたが、より完全な既存のプロジェクトが存在する場合はそれを活用したいと考えています。そのようなプロジェクトがない場合は、別のパターン/イディオム アノテーション プロジェクトにスピンオフすることで、私が持っているものを共有できるかもしれません。
更新:この議論に応えて、 Pattern Notes プロジェクトを作成しました。貢献を歓迎します! ここは@Builder
これは私には注釈の誤用のように思えます。確かに、クラスが実装に役立つデザインパターンに注意したい理由はわかりましたが、Javadocやクラスの名前を使用する方が適切なようです。使用しているパターンの名前は、コード自体にとって実際には重要ではありません...パターンは、問題を解決するためによく使用される方法のガイドにすぎません。使用するパターンごとに新しいファイルを作成するのではなく、コメントで十分です。
これは興味深い解決策ですが、これで解決しようとしている実際の問題は何なのか、ずっと疑問に思っています。または、言い換えれば、このようなものを使用して、その使用法についてクラスの上に適切なコメントを付けることによって得られないものは何ですか?
いくつかの短所は考えられますが、これがコードを文書化するための優れた標準化された方法であること以外の利点は考えられません。
短所は次のとおりです。
Michael Hunger と私は、クラスが属するパターンを指定するアノテーションのオープンソース プロジェクトを開始しました。まだ始まったばかりですが、皆様のご意見をお待ちしております。
注釈をできるだけ簡単に使用できるようにするために、KISS の原則を採用したいと考えています。たとえば、アダプターを作成している場合は、次のように簡単に言えます。
@AdapterPattern
public class EnumerationIteratorAdapter<T> implements Enumeration<T> {
...
}
もちろん、役割、参加者、コメントなど、必要に応じてさらに情報を指定することもできます。これにより、開発者がクラスを明確にマークアップすることが容易になることを願っています。
プロジェクトのホームはhttp://www.jppatterns.orgにあり、ここから初期ソース ツリーにアクセスすることもできます。プロジェクトに貢献したい場合は、heinz (javaspecialists dot eu) で私に連絡してください。
Heinz (Java スペシャリストのニュースレター)
私はちょうどあなたにとって興味深い別の記事に出くわしました：デザインマーカー-のようなマーカーインターフェースについて話している私たちの残りのための明示的なプログラミングSerializable。
彼らの言葉で：
...クラスが「Serializableを実装する」と宣言したからといって、Serializableコントラクトが正しく実装されているとは限りません。
Javaはコントラクトが満たされているかどうかを実際に判断できないため、マーカーインターフェイスを使用することは、プログラマーによる明示的な誓約です。
マーカーインターフェイスの見落とされている利点は、契約が満たされるべきであるという意図も文書化することです...
デザインの選択が伝統的にソースコードに記録されていないのはなぜですか？主に、それらを置く明確な場所がなかったためです。
各「タイプセーフ列挙」クラスに、そのパターンに従っていることを示すコメントがあったとしても、それを繰り返しコピーするか、さらに悪いことに、任意の場所に散発的に配置する必要があるため、詳細（チュートリアル情報ははるかに少ない）は追加されませんでした。
各デザインマーカーインターフェイスに添付されたJavaDocコメントを作成する場合、コメントを他の場所で繰り返す必要がないため、通常よりも詳細に入力できます。
彼らはまた、いくつかの欠点についても言及しています、これは思考のための良い食べ物です！
アノテーションを使用して、ビルダーの定型文を実際に作成する方がよいでしょう。ほとんどがかなり標準的であることに直面しましょう。
@Builder("buildMethodName")
Class Thing {
String thingName;
String thingDescr;
}
典型的な使用法：
Thing thing =
new Thing.Builder().setThingName("X").setThingDescr("x").buildMethodName();
私には注釈の誤用のようです。これらのアノテーションを使用して動作を実装する意図がない限り、KISSの原則を使用します。javadocを拡張するためのカスタムドックレット。XまたはYパターンが何のためにあるのか（またはWeb上のどこかにあるパターンへのリンク）を知りたい人のためにグーグルで検索してください。
そこにあるほとんどのパターンについて、優れた準公式の説明があります。なぜあなた自身を書くのですか？プロジェクトにとって重要な追加情報はありますか？アノテーションを使用して、あるクラスのjavadocからカスタム作成されたパターンに移動できることを確認するjavadocは、既存の2つの四半期レポートの合計を組み合わせたレポートを作成するために開発チームを編成したCEOの話のようなものです-難しすぎました（そしてさらに安い）年に4回計算機で2つの合計を追加する：-/
それ以外に、2008 年のコンピューター サイエンスの論文: Design Pattern Implementation in Java and AspectJが OOPSLA 2008 で発表されました。
それからの素敵な引用：
... パターンコードのみを含むクラスの単なる存在は、どのパターンが使用されているかの記録として機能します。AspectJ のケースでは、さらに 2 つの改善が見られます。まず、特定のパターン インスタンスに関連するすべてのコードは、単一のモジュール (参加者の定義、ロールの割り当てなど) に含まれています。これは、パターン インスタンスの記述全体がローカライズされ、システム内で「失われる」[21] または「退化する」[7] ことがないことを意味します。第二に、現在の AspectJ IDE サポートでは、すべての参照、推奨される方法などは、開発者が役割の割り当ての概要と、関心のある概念的な操作がどこにあるのかを示すハイパーリンクです...
パターンの特定のプロパティを検証する注釈プロセッサも作成できる場合 (たとえば、パターンを実装する際のよくある間違いをチェックする場合)、これは非常に便利です。コンパイラーとプログラマーのドキュメント。
まず第一に、これは非常に良いアイデアであり、「デザイン パターン アノテーション」ライブラリをグーグル検索したため、ここにたむろしているだけです。よし、これ見つけた！私はそれをチェックアウトし、すぐにフィードバックを返します。
すべての懐疑論者へ: 申し訳ありませんが、ほとんどの人はデザイン パターンのトピックについてあまり経験がありません。たとえば、2009 年 12 月 3 日 21:56 の Martin Harris の投稿 ...「例」をシンプルに保ちたいとのことは理解しています。しかし、それはデザイン パターンの意味でのビルダーではありません。
有用性がまったくわからない人にも同じことを言いたいです。設計パターンにおけるクラスの役割に関するクラスの関係がクラスに注釈付けされている場合、ジェネレーターを使用してボイラープレート コードを作成できます。ソース コード内のクラスの上にすべての関係が表示され、IDE ショートカットを使用して関連するクラスに移動できます。
パターンで考える方法を学び、すべてのパターンが (コメントまたは注釈を介して) ソース コードで明らかな場合は、200 クラスで構成されるシステムを 1 時間以内に把握できます。
@UsePattern() や @Builder("buildMethodName") などを使用するような提案について... ここで、「typesave」にする方法を尋ねなければなりませんか? 結局のところ、これらの文字列はタイプミスを起こしやすいです。
適切なアノテーションの利点の 1 つは、ロールにアノテーションを付けることができることです。ほとんどのデザイン パターンは、単一のクラス (Singleton など) からではなく、連携して動作する複数のクラスから構成されています! たとえば、ビルダーがある場合、(@Product で注釈が付けられた) 結果も @Composite になる可能性があります。そのため、ビルダーがまとめるパーツは、@Component (@Composite に関して) と @Part (@Builder および @Product に関して) になります。
おそらく、そのような注釈に対する最良の引数は java.lang.class でしょう。それを表現できます。
とにかく、ちょっと考えてみます...家に帰って、あなたが持っているもので遊ぶのが待ちきれません^^