4

何も返さない抽象クラスの mustoverride/overridable メソッドのベスト プラクティスは何ですか。この抽象クラスを継承する具象クラスは、その機能が必要かどうかを判断でき、必要に応じてオーバーライドできます。

これはインターフェースの機能であることがわかりましたが、これを実装するには「非表示にする」必要がある抽象クラスに多くの配管コードがあります。

私の質問は、プロジェクトにこれらのメソッドを含めるのは悪い設計ですか?

例 1 - Concrete クラスには実装が必要ですが、メソッドをオーバーライドする必要があります。

（概要） 

Friend MustOverride Function GetTitle() As String

（コンクリート）

Friend Overrides Function GetTitle() As String 
        Return nothing
End Function

例 2 - 具象クラスは必要に応じてメソッドをオーバーライドできますが、抽象クラスには何も返さないメソッドが含まれています。

（概要） 

Friend Overridable Function GetTitle() As String
        Return nothing
End Function

（コンクリート）

Friend Overrides Function GetTitle() As String
        Return "Title"
End Function
4

1 に答える 1

3

「わからない」をどのように示すかは、実際にはあなた次第です。しかし、抽象基底クラスから Nothing を返すのは、かなりお粗末な習慣です。クラスから派生したプログラマーまたはクライアント コードを作成したプログラマーが Nothing が可能な値であることを認識していない場合、クライアント コードで NullReferenceException が生成される可能性があります。NRE は診断が難しい例外であり、CLR はそれについて意味のあるヒントを与えることができません。たとえば、 null を格納する変数に名前を付けることはできません。たとえば、 Nothingを知っています。

これは、問題が発生する場所から少なくとも2レベル離れた場所で null が生成されるため、診断が特に困難になります。クラッシュに悩まされているユーザーは、問題の真相を突き止めるために3 人のプログラマーに相談する必要があるかもしれません。そして、ついに電話に出ることができて、とても嬉しく思います。

メンバーの意味のある実装を提供できない場合は、それを抽象宣言することを躊躇しないでください。これにより、腹を立てているユーザーと話すのはあなたではないことが保証されます。String.Empty を返すことも代替手段です。多分それはあなたのデザインにとって理にかなっていますが、私には推測できません。

于 2013-06-27T13:36:43.473 に答える