c# - C#のファクトリパターン:オブジェクトインスタンスがファクトリクラスによってのみ作成されるようにする方法は?

Question

最近、コードの一部を保護することを考えています。オブジェクトを直接作成できないようにする方法に興味がありますが、ファクトリクラスのメソッドを介してのみ作成できます。いくつかの「ビジネスオブジェクト」クラスがあり、このクラスのすべてのインスタンスが有効な内部状態を持つようにしたいとします。これを実現するには、オブジェクトを作成する前に、おそらくそのコンストラクターでいくつかのチェックを実行する必要があります。このチェックをビジネスロジックの一部にすることを決定するまでは、これで問題ありません。では、ビジネスロジッククラスの何らかのメソッドを介してのみビジネスオブジェクトを作成可能にし、直接は作成できないようにするにはどうすればよいでしょうか。C++ の古き良き "friend" キーワードを使用したいという最初の自然な欲求は、C# では不十分です。だから、他のオプションが必要です...

いくつかの例を試してみましょう:

public MyBusinessObjectClass
{
    public string MyProperty { get; private set; }

    public MyBusinessObjectClass (string myProperty)
    {
        MyProperty = myProperty;
    }
}

public MyBusinessLogicClass
{
    public MyBusinessObjectClass CreateBusinessObject (string myProperty)
    {
        // Perform some check on myProperty

        if (true /* check is okay */)
            return new MyBusinessObjectClass (myProperty);

        return null;
    }
}

入力をチェックせずに MyBusinessObjectClass インスタンスを直接作成できることを思い出すまでは、問題ありません。その技術的な可能性を完全に排除したいと思います。

それで、コミュニティはこれについてどう思いますか？

score 69 · Accepted Answer

コンストラクタを非公開にし、ファクトリをネストされた型にすることができます。

public class BusinessObject
{
    private BusinessObject(string property)
    {
    }

    public class Factory
    {
        public static BusinessObject CreateBusinessObject(string property)
        {
            return new BusinessObject(property);
        }
    }
}

これが機能するのは、入れ子になった型が、それを囲む型のプライベートメンバーにアクセスできるためです。少し制限があることは承知していますが、役に立てば幸いです...

score 56 · Accepted Answer

オブジェクトを作成する前にいくつかのビジネスロジックを実行したいだけのように見えます。では、「BusinessClass」内にすべてのダーティな「myProperty」チェック作業を行う静的メソッドを作成し、コンストラクターを非公開にしないのはなぜですか?

public BusinessClass
{
    public string MyProperty { get; private set; }

    private BusinessClass()
    {
    }

    private BusinessClass(string myProperty)
    {
        MyProperty = myProperty;
    }

    public static BusinessClass CreateObject(string myProperty)
    {
        // Perform some check on myProperty

        if (/* all ok */)
            return new BusinessClass(myProperty);

        return null;
    }
}

それを呼び出すのは非常に簡単です：

BusinessClass objBusiness = BusinessClass.CreateObject(someProperty);

score 15 · Accepted Answer

MyBusinessObjectClass クラスのコンストラクターを内部にし、コンストラクターとファクトリを独自のアセンブリに移動できます。これで、ファクトリだけがクラスのインスタンスを構築できるようになります。

score 7 · Accepted Answer

Jonが提案したこととは別に、ファクトリメソッド（チェックを含む）を最初にBusinessObjectの静的メソッドにすることもできます。次に、コンストラクターを非公開にすると、他のすべての人は強制的に静的メソッドを使用するようになります。

public class BusinessObject
{
  public static Create (string myProperty)
  {
    if (...)
      return new BusinessObject (myProperty);
    else
      return null;
  }
}

しかし、本当の問題は、なぜこの要件があるのかということです。ファクトリまたはファクトリメソッドをクラスに移動することは許容されますか?

score 4 · Accepted Answer

もう 1 つの (軽量) オプションは、BusinessObject クラスで静的ファクトリメソッドを作成し、コンストラクターを非公開にすることです。

public class BusinessObject
{
    public static BusinessObject NewBusinessObject(string property)
    {
        return new BusinessObject();
    }

    private BusinessObject()
    {
    }
}

score 2 · Accepted Answer

インターフェイスと実装が適切に分離されている場合、
protected-constructor-public-initializer パターンを使用すると、非常にうまく解決できます。

与えられたビジネスオブジェクト:

public interface IBusinessObject { }

class BusinessObject : IBusinessObject
{
    public static IBusinessObject New() 
    {
        return new BusinessObject();
    }

    protected BusinessObject() 
    { ... }
}

そしてビジネス工場：

public interface IBusinessFactory { }

class BusinessFactory : IBusinessFactory
{
    public static IBusinessFactory New() 
    {
        return new BusinessFactory();
    }

    protected BusinessFactory() 
    { ... }
}

BusinessObject.New()初期化子への次の変更により、解決策が得られます。

class BusinessObject : IBusinessObject
{
    public static IBusinessObject New(BusinessFactory factory) 
    { ... }

    ...
}

BusinessObject.New()ここでは、イニシャライザを呼び出すために具体的なビジネスファクトリへの参照が必要です。しかし、必要なリファレンスを持っているのはビジネスファクトリーだけです。

私たちは望んでいたものを手に入れました: 作成できるのはだけBusinessObjectですBusinessFactory.

score 2 · Accepted Answer

    public class HandlerFactory: Handler
    {
        public IHandler GetHandler()
        {
            return base.CreateMe();
        }
    }

    public interface IHandler
    {
        void DoWork();
    }

    public class Handler : IHandler
    {
        public void DoWork()
        {
            Console.WriteLine("hander doing work");
        }

        protected IHandler CreateMe()
        {
            return new Handler();
        }

        protected Handler(){}
    }

    public static void Main(string[] args)
    {
        // Handler handler = new Handler();         - this will error out!
        var factory = new HandlerFactory();
        var handler = factory.GetHandler();

        handler.DoWork();           // this works!
    }

score 2 · Accepted Answer

だから、私が望むことは「純粋な」方法ではできないようです。これは常に、ロジッククラスへの何らかの「コールバック」です。

多分私は簡単な方法でそれを行うことができます.オブジェクトクラスのコンストラクターメソッドが最初にロジッククラスを呼び出して入力をチェックするだけですか?

public MyBusinessObjectClass
{
    public string MyProperty { get; private set; }

    private MyBusinessObjectClass (string myProperty)
    {
        MyProperty  = myProperty;
    }

    pubilc static MyBusinessObjectClass CreateInstance (string myProperty)
    {
        if (MyBusinessLogicClass.ValidateBusinessObject (myProperty)) return new MyBusinessObjectClass (myProperty);

        return null;
    }
}

public MyBusinessLogicClass
{
    public static bool ValidateBusinessObject (string myProperty)
    {
        // Perform some check on myProperty

        return CheckResult;
    }
}

この方法では、ビジネスオブジェクトを直接作成することはできず、ビジネスロジックのパブリックチェックメソッドも害を及ぼすことはありません。

score 1 · Accepted Answer

ファクトリをドメインクラスと同じアセンブリに配置し、ドメインクラスのコンストラクターを internal としてマークします。このようにして、ドメイン内のどのクラスでもインスタンスを作成できる可能性がありますが、そうしないと信じていますよね? ドメイン層の外でコードを書く人は誰でもあなたの工場を使わなければなりません。

public class Person
{
  internal Person()
  {
  }
}

public class PersonFactory
{
  public Person Create()
  {
    return new Person();
  }  
}

ただし、私はあなたのアプローチに疑問を持たなければなりません:-)

作成時に Person クラスを有効にしたい場合は、コードをコンストラクターに入れる必要があると思います。

public class Person
{
  public Person(string firstName, string lastName)
  {
    FirstName = firstName;
    LastName = lastName;
    Validate();
  }
}

score 1 · Accepted Answer

さまざまなトレードオフを伴う複数のアプローチが言及されています。

ファクトリクラスをプライベートに構築されたクラスにネストすると、ファクトリは 1 つのクラスのみを構築できます。その時点で、Createメソッドとプライベート ctor を使用したほうがよいでしょう。
継承と保護された ctor の使用には同じ問題があります。

ファクトリを、ネストされたプライベートクラスとパブリックコンストラクタを含む部分クラスとして提案したいと思います。ファクトリが構築しているオブジェクトを 100% 非表示にし、選択したもののみを 1 つまたは複数のインターフェイスを介して公開します。

私が聞いた使用例は、工場内のインスタンスを 100% 追跡したい場合です。この設計は、「工場」で定義された「化学物質」のインスタンスの作成に工場以外の誰もアクセスできないことを保証し、それを達成するための別のアセンブリの必要性を取り除きます。

== ChemicalFactory.cs ==
partial class ChemicalFactory {
    private  ChemicalFactory() {}

    public interface IChemical {
        int AtomicNumber { get; }
    }

    public static IChemical CreateOxygen() {
        return new Oxygen();
    }
}


== Oxygen.cs ==
partial class ChemicalFactory {
    private class Oxygen : IChemical {
        public Oxygen() {
            AtomicNumber = 8;
        }
        public int AtomicNumber { get; }
    }
}



== Program.cs ==
class Program {
    static void Main(string[] args) {
        var ox = ChemicalFactory.CreateOxygen();
        Console.WriteLine(ox.AtomicNumber);
    }
}

score 0 · Accepted Answer

問題よりも悪くない解決策はないと思います。上記のすべては、IMHOがより悪い問題であり、オブジェクトを使用するためにファクトリを呼び出すだけの人々を止めることのない公共の静的ファクトリを必要とします-それは何も隠しません。アセンブリは信頼できるコードであるため、インターフェースを公開するか、コンストラクターを内部として保持するのが最善です。これが最善の保護です。

1つのオプションは、IOCコンテナーのようなものでファクトリをどこかに登録する静的コンストラクターを持つことです。

score 0 · Accepted Answer

これは、「できるからといって、すべきであるとは限らない」という意味での別の解決策です...

これは、ビジネスオブジェクトコンストラクターをプライベートに保ち、ファクトリロジックを別のクラスに配置するという要件を満たしています。その後は少し大雑把になります。

ファクトリクラスには、ビジネスオブジェクトを作成するための静的メソッドがあります。プライベートコンストラクターを呼び出す静的な保護された構築メソッドにアクセスするために、ビジネスオブジェクトクラスから派生します。

ファクトリは抽象的であるため、実際にそのインスタンスを作成することはできません (ビジネスオブジェクトでもあるため、奇妙になります)。プライベートコンストラクターがあるため、クライアントコードはそこから派生できません。

防止されていないのは、クライアントコードもビジネスオブジェクトクラスから派生し、保護された (ただし検証されていない) 静的構築メソッドを呼び出すことです。さらに悪いことに、最初にコンパイルするファクトリクラスを取得するために追加しなければならなかった保護されたデフォルトコンストラクタを呼び出します。(ちなみに、ファクトリクラスとビジネスオブジェクトクラスを分離するパターンでは、これが問題になる可能性があります。)

正気の人なら誰でもこのようなことをすべきだと言っているわけではありませんが、これは興味深い演習でした。FWIW、私の好ましい解決策は、内部コンストラクターとアセンブリ境界をガードとして使用することです。

using System;

public class MyBusinessObjectClass
{
    public string MyProperty { get; private set; }

    private MyBusinessObjectClass(string myProperty)
    {
        MyProperty = myProperty;
    }

    // Need accesible default constructor, or else MyBusinessObjectFactory declaration will generate:
    // error CS0122: 'MyBusinessObjectClass.MyBusinessObjectClass(string)' is inaccessible due to its protection level
    protected MyBusinessObjectClass()
    {
    }

    protected static MyBusinessObjectClass Construct(string myProperty)
    {
        return new MyBusinessObjectClass(myProperty);
    }
}

public abstract class MyBusinessObjectFactory : MyBusinessObjectClass
{
    public static MyBusinessObjectClass CreateBusinessObject(string myProperty)
    {
        // Perform some check on myProperty

        if (true /* check is okay */)
            return Construct(myProperty);

        return null;
    }

    private MyBusinessObjectFactory()
    {
    }
}

c# - C#のファクトリパターン:オブジェクトインスタンスがファクトリクラスによってのみ作成されるようにする方法は?

17 に答える 17

Related

Reference