7

私はインターフェースに対するプログラミングにかなり慣れておらず、テスト駆動開発の主要なツールとしてそれを正しくしようとしています。

現在、すべてがインターフェースを実装する多くのManagerクラスがありCRUDます。ただし、一部のマネージャーはまだ更新を行わず、一部は削除を行わず、一部のマネージャーは削除しない場合があります。

実装されていない例外？

大丈夫ですか

throw new NotImplementedException()

メソッドが実装されるまで、または実装されない場合は常に実行されますか？

（明らかに、プログラマーに「このメソッドは使用されるべきではありません。たとえば、「male」「female」などのタイプは削除されないため）というソースコードコメントがありますか？

スプリット？

または、CRUDインターフェイスを作成可能、読み取り可能（検索可能）、更新可能、削除可能に分割する必要がありますか？それは私のクラス定義を乱雑にしませんか？

PersonManager implements Creatable<Person>, Updateable<Person>, Deletable<Person>, Searchable<Person>

分割して結合しますか？

または、4つすべてのようないくつかのインターフェイスをCRUDに組み合わせたり、Read + Updateのような他の組み合わせを組み合わせたりする必要がありますか？

たぶん、それはまた、大きな継承パスをクリックして、現在の状況に必要なすべてのアトミックインターフェイスを実装するインターフェイスを見つける必要があるインターフェイスの負荷を作成します（読み取りと作成が必要なので、どちらが2つを実装するだけですか？）これはすぐにもっと複雑になる可能性があります）

4

4 に答える 4

6

IMO、中間段階ではNotImplementedException、実装が完了するまで使用しても問題ありません。

ただし、恒久的な解決策としては、 [ほとんどの場合] 悪い習慣だと思います。

代わりに、すべての実装クラスに共通の動作を含むインターフェイスを作成し、サブインターフェイスを使用してそれらをより具体的な動作にクラスター化します。

SortedSetこの考え方は、 a - を拡張するJava standard に似ています。この目的のために、代わりにサブインターフェースを使用して、 s と見なしてこの型の変数に の値を与えSetたくありません。SetSortedSetHashSetSortedSet

于 2012-04-19T08:42:49.037 に答える
6

UnsupportedOperationException一般に、要求された操作がサポートされていないことを明確に述べて、実行時例外をスローしたいと考えています。

インターフェースがたくさんあると、ファイルが多くなりすぎます。また、誰かがそれらを見ようとすると、混乱してしまいます。このような場合、Java ドキュメントもあまり役に立ちません。

1 つのインターフェースに対する操作が多すぎて、すべての操作が論理的に結合されているわけではない場合、インターフェースの分割は理にかなっています。

ほとんどのシナリオに当てはまる基本的な操作があるため、データベース操作の場合はめったにありません。

于 2012-04-19T08:43:08.463 に答える
1

NotImplementedException は、クラスがこのアクションをサポートしていないという意味ではありません。実装されていないことを意味しますが、将来実装される予定です。

論理的な観点からは、すべてのインターフェイス メソッドを実装し、適切に機能させる必要があります。しかし、それをそのままにして、自分だけのアプリケーションを作成すると、この制限について思い出すでしょう。一方で、一部の開発者がインターフェースを実装し、それを未実装のままにしたことに腹を立てます。したがって、将来の開発のためだけにインターフェースメソッドを実装しないままにしておくことはできないと思います。

私の提案は、インターフェイスを変更してから、実装されたメソッド内で例外を使用することです。

于 2012-04-19T08:45:55.120 に答える
0

共分散と反分散をサポートするフレームワークでは、インターフェイスを分割してからいくつかの複合インターフェイスを定義すると非常に便利です。そのようなサポートを提供しないフレームワークの場合 (場合によっては提供するフレームワークでも)、個々の実装がサポートするかどうかを示すメソッドをインターフェースに含めると、より便利な場合があります (サポートされていないアクションが試行された場合、実装は例外をスローする必要があります)。それを行う場合は、例外をスローするコードを使用する必要なく、サポートされているアクションを外部コードが確認できるメソッドまたはプロパティを含める必要があります。

ただし、アクションのサポートがオプションであるインターフェースを使用する場合でも、特定のアクションが使用可能であることを保証する追加のインターフェースを定義すると役立つ場合があります。新しいメンバーを追加せずに他のインターフェイスを継承するインターフェイスを持つことは、これを行うための良い方法です。適切に行われた場合、実装に代わってこれが必要とする唯一の追加作業は、適用可能な最も具体的な型として自分自身を宣言することです。クライアントの状況はもう少し複雑です。クライアントのニーズを型システムで適切に表現できる場合、クライアントは特定の型を要求することで実行時の型チェックの必要性を回避できます。一方、クライアント間でインスタンスを渡すルーチンは、一部のクライアントによって複雑になる場合があります。

于 2012-04-19T16:27:35.313 に答える