API についてよくわからない場合でも、ポリモーフィズムやインターフェイスを使用すると、プロジェクトでこれらのライブラリを簡単に使用できますか?
そうではありませんが、API に関するドキュメントと API の設計は、API を使いやすくするための主要な方法です。API の使用は学習タスクであり、ドキュメントは優れたチュートリアルまたはレッスンのようなものですが、API 設計の改善は学習する資料を簡素化するようなものです。
このタイプのプロジェクトで Polymorphisim や Interface を使用すると、単体テストはどのようなものになりますか?
オブジェクトのメソッドまたは複数のメソッドを呼び出して結果を確認するという意味では、ほとんどの場合、単体テストは似ています。
Polymorphisim を使用すると、主に継承ツリーの下部にあるクラスをテストし、Interface を使用して、継承ツリーの下部にあるクラスを主にテストします。これは、単体テスト時に意味のある方法で抽象クラスまたはインターフェイスをインスタンス化できないためです。
一般的に、ドキュメンテーションが不十分なサードパーティ製ライブラリを使用して開発する場合のベスト プラクティスは何ですか?
一般に、ベスト プラクティスは、仮定を検証する小さなコードを記述し、それらを実行して、ライブラリがどのように機能すると考えているかについて、仮定が正しいかどうかを確認することです。
他の手法には、ライブラリのソース コードをダウンロードして、利用可能な場合はそれを読み取ることが含まれます。「ライブラリをテストする」ための単体テストを書くことはこの方法で役に立ちますが、これを簡単にするためにライブラリが適切に構造化されていない場合があります。
たとえば、ライブラリを紹介する本を購入するなど、他の方法でドキュメントを入手できる場合があります。ライブラリのベンダーから「トレーニング」クラスを受講できる場合もあります。ライブラリを使用している他の人を見つけて質問することもできます (これには、ライブラリ固有のユーザー グループやメーリング リストが含まれることがよくあります)。ライブラリのバグ追跡システムにアクセスして、バグの送信から詳細を見つけることができる場合があります (または、関数の適切な使用方法を示すバグの送信の拒否など)。場合によっては、同じライブラリを使用している他のプロジェクトを見つけて、そのソース コードを読んで、機能していると思われる使用パターンを判断できます。
ライブラリは通常、使用するために作成されますが、誰もが使用するライブラリを作成するのが得意というわけではありません。著者が情報を提供しても、それがどこにあるのかわからない場合もあれば、別の視点を持つために必要な能力が著者に欠けていて、それを効果的に使用する方法を示していない場合もあります。一般に、使用するのが難しすぎるライブラリはほとんど使用されず、最終的には忘れられて使用されなくなります。