0

私はちょうど次のような記事を読んでいます。

サブクラス結合。基本型 (通常はクラス) にそれを拡張する多数の派生型がある場合、理想的には、他の型は基本型のみを認識している必要があります。すべてのサブタイプが同じパブリック インターフェイスを共有している場合 (パブリック メンバーは基本タイプから継承され、各サブクラスで異なる動作のために上書きされます)、外部の「クライアント」タイプはそれらを基本クラスであるかのようにすべて同じように扱うことができます。そうでない場合、クライアント タイプが存在するサブタイプの詳細を知っている場合、これは問題のポリモーフィック構造へのサブクラス結合です。

具体的には、最後の行は、「クライアント タイプが、存在するサブタイプの詳細を知っている場合...」と述べています。.NET では、 を使用すると、 が返されること、およびプロパティなどのサブクラスに固有のプロパティを変更できることがWebRequest.Create("ftp://...");わかっています。WebRequest のサブタイプに関する具体的な知識がない限り、これを行うことはできないので、これはサブクラス結合のケースであり、設計が悪いと思います。FtpWebRequestFtpWebRequestUseBinary

.NET フレームワークの開発者に代わって、これが悪い設計であると信じるのに苦労しています。代わりに、上記の私の理解が少しずれていると想像してください。私が .NET で提供した例がサブクラス結合の例ではない理由を誰かが説明できますか?

4

1 に答える 1

1

状況次第だと思います。多くの場合、のような具体的なタイプで作業したくない場合は、FtpWebRequestそのタイプに結合するためです。代わりに、と呼ばれるインターフェイスに対して作業する場合、IRequestまたはIWebRequestそれらのインターフェイスの具体的な実装にそれほど結合されない場合は、ほとんどの場合、コードのテストが容易になり、ftpからに移行する際の苦痛が少なくなります。使用しているインターフェースに準拠している限り、他のプロトコル。しかし、本当に単純なことをしている場合は、インターフェースが作成する追加の抽象化レイヤーを配置する必要がない場合があります。

簡単な例：

public interface IDoSomething { void DoSomething(); }
public class DoSomethingA { public void DoSomething(); }
public interface DoSomethingB { public void DoSomething(); }

public class UseDoSomething
{
    public UseDoSomething(IDoSomething do) { do.DoSomething(); }
}

クラスのあなたがUseDoSomething具体的なタイプの1つを取り入れた場合; DoSomethingAまたはDoSomethingB、その実装に向けてより緊密な結合が得られます。私が提供した例では、の実装をIDoSomething入力として自由に使用できますUseDoSomething。これは、将来に最適であり、テストも容易になります。すべてが要件などに依存することに気付くかもしれませんが、そのタイプの特定のものにアクセスする必要があるため、具体的なタイプを使用する必要があるかもしれません。そうすることで問題ない場合があります。

はっきりさせますか？

于 2012-03-01T12:00:03.473 に答える