78

私はC＃に比較的慣れていないので、C＃プロジェクトに取り掛かるたびに（C＃ではほぼ成熟したプロジェクトにしか取り組んでいません）、なぜ内部クラスがないのでしょうか。

多分私は彼らの目標を理解していません。私にとって、内部クラス（少なくともプライベート内部クラス）は、Pascal / Modula-2 / Adaの「内部プロシージャ」によく似ています。理解を容易にするために、メインクラスをより小さな部分に分割することができます。

例：これがほとんどの場合に見られるものです：

public class ClassA
{
   public MethodA()
   {
      <some code>
      myObjectClassB.DoSomething(); // ClassB is only used by ClassA
      <some code>
   }
}

public class ClassB
{
   public DoSomething()
   {
   }
}

ClassBは（少なくともしばらくの間）ClassAによってのみ使用されるため、このコードは次のように表現した方がよいと思います。

   public class ClassA
   {
      public MethodA()
      {
         <some code>
         myObjectClassB.DoSomething(); // Class B is only usable by ClassA
         <some code>
      }

      private class ClassB
      {
         public DoSomething()
         {
         }
      }
   }

この件についてあなたから聞いてうれしいです-私は正しいですか？

4

4 に答える 4

82

ネストされたクラス (C# のネストされたクラスは Java の内部クラスとは多少異なるため、「内部」という言葉を避けるのがおそらく最善です) は実際に非常に便利です。

言及されていないパターンの 1 つは、"better enum" パターンです。これは、Java のものよりもさらに柔軟です。

public abstract class MyCleverEnum
{
    public static readonly MyCleverEnum First = new FirstCleverEnum();
    public static readonly MyCleverEnum Second = new SecondCleverEnum();

    // Can only be called by this type *and nested types*
    private MyCleverEnum()
    {
    }

    public abstract void SomeMethod();
    public abstract void AnotherMethod();

    private class FirstCleverEnum : MyCleverEnum
    {
        public override void SomeMethod()
        {
             // First-specific behaviour here
        }

        public override void AnotherMethod()
        {
             // First-specific behaviour here
        }
    }

    private class SecondCleverEnum : MyCleverEnum
    {
        public override void SomeMethod()
        {
             // Second-specific behaviour here
        }

        public override void AnotherMethod()
        {
             // Second-specific behaviour here
        }
    }
}

いくつかの言語サポートを使用して、これを自動的に行うことができます。すべての値に対してネストされたクラスを実際に使用しない、または複数の値に対して同じネストされたクラスを使用するなど、ここでは示していない多くのオプションがあります。しかし、それらに異なるコンストラクターパラメーターを与えます。しかし、基本的に、ネストされたクラスがプライベート コンストラクターを呼び出すことができるという事実は、多くの機能を提供します。

于 2009-01-17T23:29:26.397 に答える
31

Framework Design Guidelinesには、これまでに見つけたネストされたクラスを使用するための最良のルールがあります。

簡単な要約リストは次のとおりです。

  1. 型と入れ子にされた型の間の関係が、メンバーのアクセシビリティ セマンティクスが必要な場合は、入れ子にされた型を使用してください。

  2. ネストされた public 型を論理グループ構造として使用しないでください

  3. 公開されているネストされた型の使用は避けてください。

  4. 型が含まれている型の外部で参照される可能性が高い場合は、入れ子になった型を使用しないでください。

  5. クライアント コードでインスタンス化する必要がある場合は、入れ子になった型を使用しないでください。

  6. ネストされた型をインターフェイスのメンバーとして定義しないでください。

于 2009-11-12T20:10:04.890 に答える
12

各クラスの責任を制限して、それぞれがシンプルで、テスト可能で、再利用可能であるようにする必要があります。プライベート内部クラスはこれに反します。それらは外部クラスの複雑さに貢献し、テスト可能ではなく、再利用可能ではありません。

于 2009-01-17T23:47:35.360 に答える
3

個人的には、メソッドを必要とする可能性のあるオブジェクトのインプロセス コレクションを作成する必要がある場合にのみ、プライベート 内部クラスを作成します。

そうしないと、プロジェクトで作業している他の開発者が実際にこれらのクラスを見つけて混乱する可能性があります。

于 2009-01-17T22:48:05.637 に答える