0

私は「GWTinaction2」という本を読んでいて、著者は（開発者が別のウィジェットを拡張してカスタムウィジェットを作成できるセクションで）スーパークラスの一部の機能、つまりメソッドを停止/抑制する方法についてのヒントを述べました。実装されたインターフェースによって与えられます。

著者が提供した方法は、メソッドをオーバーライドし、開発者のGWTログに例外を追加することでした。例：

public HandlerRegistration addClickHandler(ClickHandler handler){ 
    GWT.log("", new Exception("Cannot add ClickHandler to ReportSizeLabel"));                      
    return null;                                                  
}

なぜ私はそれをするのですか、これは良いデザインですか？

あなたがそのようなことをしなければならないのなら、なぜ単にnullを返さないのですか？

とにかく考えすぎかもしれませんが、ありがとうございます。

4

2 に答える 2

3

これは基本的に悪いことだと思います。nullを返すことは、プログラマーにとっては役に立ちません（例外をスローする方がよいでしょう）。そして、すべてがポリモーフィズムの概念を壊します。

したがって、正しい答えは、インターフェイスの代替チェーンを作成して、必要なすべての関数を取得することですが、を含めることはできませんHasClickHandlers。ただし、実際には、これには多くの時間がかかる可能性があります。この関数がnullを返す代わりに例外をスローした場合、私はそれを内部で使用されるコードに入れても構わないと思いますが、他の人が使用するためにこのコードを公開することはありません。

PS：正しい答えは、おそらくメソッドを正しく実装することです。この場合、それほど難しくはありません。

于 2012-07-10T19:36:10.330 に答える
-1

私はこれに本質的に悪いことは何も見ていません。親の関数が子にとって論理的に意味をなさない場合、それを無効にすることは合理的なことのように思われます。エラーをログに記録すると、エラーが発生したことがわかります。

無効にする方法としてnullを返すことが良い考えであるかどうかは、関数が何をするかによって異なります。呼び出し元がnullリターンをチェックしてから、パニックアボート関数を呼び出す場合は、例外をスローする方が理にかなっています。ただし、関数が「通常」、たとえばコレクションに詰め込まれたオブジェクトを返す場合は、nullを返し、呼び出し元にコレクションにnullを入れさせるのが妥当な方法かもしれません。

確かに、親クラスまたはインターフェイスから多くの関数を無効にしていることに気付いた場合は、ある時点で、このインターフェイスを実際に実装しているのか、これに似た他のインターフェイスを実装しているのかを確認する必要があります。しかし、インターフェイスが100個の関数を宣言し、そのうち2個を無効にした場合、サブセットに新しいインターフェイスを定義するのは悪い考えだと思います。つまり、維持する必要のある98個の関数のそれぞれに2つの定義があるということです。それがインターフェースではなく親クラスである場合、これはさらに悪化します。これは、98個の関数のコピーが2つあることを意味します。重複したコードは、無効にされた機能の受け渡しよりもはるかに悪いことです。

于 2012-07-10T19:55:28.257 に答える