1

ここでいくつかの質問を読みましたが、一般的なコンセンサスは、プロジェクト内のすべてのクラスにインターフェイスは必要ないということです。次のような投稿を読みました: Is it the best practice to extract an interface for every class? .

これが .NET Framework クラスにどのように適用されるかを知りたいです。私が見たすべてのクラスは、SQLConnection が dbConnection から継承するなどの抽象クラスから継承するか、Component クラスが IComponent インターフェイスを実装するなどのインターフェイスを実装していると思います。

私は 2 か月前にダウンロードした Reflector のコピーを持っており、ライセンスを待っています (最近料金を支払いました)。(Reflector を使用して) コードをステップ実行し始めると、次のようなコードが表示されますか?

Public Class Foo
    Public Name As String
    Public Property NameProperty()
        Get
            Return Name
        End Get
        Set(value)
            Name = value
        End Set
    End Property

    Public Shared Sub Main()
        Dim f As Foo = New Foo
        f.NameProperty = "Ian"
    End Sub

End Class

次のようなコードではなく:

Public Class Foo
    Implements IFoo
    Public Name As String
    Public Property NameProperty() Implements IFoo.NameProperty
        Get
            Return Name
        End Get
        Set(value)
            Name = value
        End Set
    End Property

    Public Shared Sub Main()
        Dim f As IFoo = New Foo
        f.NameProperty = "Ian"
    End Sub

End Class

Public Interface IFoo
    Property NameProperty()
End Interface

2 番目のコード フラグメントで使用されているインターフェイスがあることに注意してください。インターフェイスを使用しないことが適切な場合を理解するのにまだ苦労しています。一部の開発者は決して言わない。主観的な部分もあると思います。

4

1 に答える 1

1

物事を正しい方法で行うよう努めている私は、新しいプロジェクトを開始するたびに苦労します。私はそれがほとんど主観的であることに気づきました。「シャワーを浴びなくてもいい日は？」と言うようなものです。

もちろん、抽象化を提供し、テスト容易性を向上させますが、不必要な「クラスの爆発」につながる可能性があります。私の経験では、補助的な内部クラスにインターフェイスを追加することは、良いことよりも害を及ぼします。私は時折、何年も前に行った小さなプロジェクトを開いて、クラスの無限のリストにショックを受けています...オーバーエンジニアリング!

原則として、クラス ライブラリ内の API のインターフェイスを使用します。それ以外では、時間が許せば追加します。または、コードのセクションがクライアント コードによってどのように呼び出されるかを明確にする必要がある場合もあります。

于 2013-03-12T16:01:48.290 に答える