8

Java で API を設計する必要があるときはいつでも、通常は IDE を開いて、パッケージ、クラス、およびインターフェースを作成することから始めます。メソッドの実装はすべてダミーですが、javadoc には詳細が記載されています。

これは物事を進めるための最良の方法ですか？私は、最初の .java ファイルが作成される前であっても、API ドキュメントを最初に作成する必要があると感じ始めています。これにはいくつかの利点があります。

  1. API 設計者は、設計と仕様を完成させてから、実装を複数の実装者に分割できます。
  2. より柔軟 - 設計を変更しても、javadoc コメントを編集する場所を探して Java ファイル間を行き来する必要はありません。

この意見を共有する他の人はいますか？もしそうなら、どのように API 設計から始めますか?

さらに、役立つツールはありますか？おそらく、ドキュメントを生成してからスケルトン ソースを生成する何らかの注釈ベースのツール (モデルからコードへのジェネレーターのようなもの) でしょうか? Eclipse PDE API ツールに出くわしましたが、これは Eclipse プラグイン プロジェクトに固有のものです。もっと一般的なものは見つかりませんでした。

4

5 に答える 5

4

API (および IMO の多くの種類の問題) では、問題の分割と分析のためのトップダウン アプローチが適しています。

ただし（これは私自身の個人的な経験に基づく私の 2c にすぎないので、大まかに考えてください）、その Javadoc 部分に焦点を当てることは良いことですが、それでも十分ではなく、信頼できるとは言えません。出発点。実際、これは非常に実装指向です。では、その前に行われるべき設計、モデリング、推論はどうなったのでしょうか (それがどんなに短いものであっても)?

API を構成するエンティティ (名詞、役割、動詞) を特定するには、何らかのモデリングを行う必要があります。そして、どんなに「アジャイル」になりたいと思っても、問題ステートメントの明確な全体像がなければ、そのようなものをプロトタイプ化することはできません (たとえそれがほんの 10K フィートのビューであっても)。

最良の出発点は、実装しようとしているもの、より正確には、API が対処しようとしている問題の種類を指定することです。BDD が役立つ場合があります (詳細は以下を参照)。つまり、API が提供するもの (データ要素) と、誰に対して、どのアクション (動詞) を実行し、どのような条件 (コンテキスト) で実行するかということです。次に、どのエンティティがこれらのものを提供し、どの役割の下で提供するかを特定します (インターフェース、具体的には、メソッドの包括的なバッグとしてではなく、単一の明確な役割または機能とのインターフェース)。これは、それらがどのようにまとめられているか (継承、構成、委任など) の分析につながります。

それができたら、準備段階のJavadocを開始するのに適した位置にいる可能性があります。次に、これらのインターフェイスやロールの実装に取り​​掛かることができます。さらに Javadoc が続きます (Javadoc に含まれない他のドキュメント、つまりチュートリアル、ハウツーなどに加えて)。

ユースケースと検証可能な要件、およびそれぞれが単独で、または共同で行うべき動作の説明から実装を開始します。BDD はここで非常に役立ちます。

作業を進めながら、できればいくつかのメトリクス (循環的複雑度とLCOM の変形) を取得して、継続的にリファクタリングします。これら 2 つは、どこをリファクタリングする必要があるかを示します。

API の開発は、アプリケーションの開発と本質的に異なるものであってはなりません。結局のところ、API はユーザー (たまたま開発の役割を持っている) にとって実用的なアプリケーションです。

そのため、API エンジニアリングを一般的なソフトウェア集約型アプリケーション エンジニアリングと区別して扱うべきではありません。同じプラクティスを使用し、必要に応じて調整すれば (ソフトウェアを扱うすべての人がそうすべきです)、うまくいくでしょう。

Google はかなり前から、YouTube に「Google Tech Talk」ビデオ講義シリーズをアップロードしています。そのうちの 1 つは、 「優れた API を設計する方法とそれが重要な理由」という 1 時間の講義です。こちらもチェックしてみるといいかもしれません。

役立つかもしれないいくつかのリンク：

Google Tech Talk の「Beyond Test Driven Development: Behavior Driven Development」: http://www.youtube.com/watch?v=XOkHh8zF33o

ビヘイビア駆動開発 : http://behaviour-driven.org/

書籍「Practical API Design」の Web サイト コンパニオン: http://wiki.apidesign.org/wiki/Main_Page

基本に戻る - 構造化された設計#結束と結合 : http://en.wikipedia.org/wiki/Structured_Design#Structured_Design

于 2011-08-05T13:04:59.807 に答える
3

最初にインターフェイスを定義することは、事前条件、事後条件、および不変条件を宣言する契約によるプログラミング スタイルです。最初に記述した不変条件と事後条件は、テストでチェックできる動作であるため、テスト駆動開発 (TDD) とうまく組み合わせることができます。

余談ですが、TDD のビヘイビア駆動型開発の精緻化は、最初にインターフェースを習慣的に考えなかったプログラマーのおかげで生まれたようです。

于 2011-08-05T12:16:00.297 に答える
2

プロトタイプを使ったコーディングに飛びつきます。必要なインターフェイスがすぐに表示され、プロトを最終製品に成形できます。可能であれば、APIを使用する予定の人からフィードバックを受け取ります。

API設計にアプローチするための「最善の方法」はありません。自分に合った方法を実行してください。ドメイン知識も重要な役割を果たします

于 2011-08-05T11:06:00.460 に答える
2

私はインターフェイスへのプログラミングの大ファンです。これは、コードの実装者とユーザーの間の契約を形成します。コードに直接飛び込むのではなく、通常、システムの基本モデル (複雑さに応じて UML ダイアグラムなど) から始めます。これは優れたドキュメントとして機能するだけでなく、システム構造を視覚的に明確にします。これにより、コーディング部分がはるかに簡単になります。また、この種の設計ドキュメントは、6 か月後にシステムに戻ったときや、バグを修正しようとしたときに、システムを理解しやすくします :) プロトタイピングにもメリットはありますが、それを捨てて最初からやり直す準備をしてください。

于 2011-08-05T11:11:25.363 に答える
2

私自身は、インターフェースとそのドキュメントを書くことから始めて、それから実装を始めることを常に好みます。

以前は、UML から始めて自動コード生成を使用するという別のアプローチを取りました。この件に関して私が見つけた最良のツールは、Rational Roseでした。これは無料ではありませんが、無料のプラグインとユーティリティがたくさんあると確信しています。私が遭遇した他の設計者に対する Rational Rose の利点は、設計をコードに「添付」し、コードまたは設計のいずれかを変更すると、もう一方が更新されることです。

于 2011-08-05T10:51:23.637 に答える