5

以下のようにファクトリパターンを実装しました。

ただし、個々のクラスは公開されているため、誰かがそれらを直接インスタンス化することを妨げるものは何もありません。

これは正しいです？具象クラスがファクトリを介してのみ作成されるようにするにはどうすればよいですか？ 

namespace MRS.Framework
{
    public  abstract class DataSource
    {
        public override string ToString()
        {
            return "DataSource";
        }
    }

    public class XMLDataSource : DataSource
    {

    }

    public class SqlDataSource : DataSource
    {

    }

    public class CSVDataSource : DataSource
    {
        public int MyProperty { get; set; }


        public override string ToString()
        {
            return "CSVDataSource";
        }
    }
}

工場での実装

namespace MRS.Framework
{
    public abstract class DataSourceFactory
    {
        public abstract DataSource CreateDataSource(DataSourceType datasourcetype);
    }

    public class CSVDataSourceFactory : DataSourceFactory
    {
        public CSVDataSourceFactory()
        {

        }
        public override DataSource CreateDataSource(DataSourceType datasourcetype)
        {
            return new CSVDataSource();
        }
    }


    public class XMLDataSourceFactory : DataSourceFactory
    {
        public override DataSource CreateDataSource(DataSourceType datasourcetype)
        {
            return new XMLDataSource();
        }
    }

    public class SqlDataSourceFactory : DataSourceFactory
    {
        public override DataSource CreateDataSource(DataSourceType datasourcetype)
        {
            return new SqlDataSource();
        }
    }

}

主要

 static void Main(string[] args)
        {
            DataSourceFactory datasourcefactory = new CSVDataSourceFactory();
            CSVDataSource ds = (CSVDataSource)datasourcefactory.CreateDataSource(DataSourceType.CSVDataSource);
            CSVDataSource myds = new CSVDataSource();
            Console.WriteLine(ds.ToString());
            Console.WriteLine(myds.ToString());
            Console.ReadLine();

        }
4

2 に答える 2

6

はい、ここでのあなたの直感は正しいです。クラスの構成を制限したいCSVDataSourceFactory場合は、アクセス修飾子が間違っています。

ただし、修正する必要があるクラスのアクセス修飾子ではなく、コンストラクターのアクセス修飾子です。internalアセンブリ内の他のクラスのみがコンストラクターを構築できるように、デフォルトのコンストラクターをマークする必要があります。もちろん、そのアセンブリ内で独自のルールを適用する必要がありますが、そのコードを完全に制御できるため、問題になることはありません。

public class XMLDataSource : DataSource
{
  internal XMLDataSource() { }
}

public class SqlDataSource : DataSource
{
  internal SqlDataSource() { }
}

public class CSVDataSource : DataSource
{
  public int MyProperty { get; set; }

  internal CSVDataSource() { }

  public override string ToString()
  {
      return "CSVDataSource";
  }
}
于 2012-05-08T15:07:11.040 に答える
2

人々がデータソースのインスタンスを作成できないようにする方法を知りたい場合は、インターフェースを介してそれを行うことができます。公開するすべてのメソッドを使用して、データソースごとにインターフェイスを作成します。クラス自体を内部クラスにするか、ファクトリのプライベート内部クラス（通常は内部クラスが適切です）とインターフェイスをパブリックにします。

問題が、人々がインスタンスを作成するのをどのように阻止するかではなく、そうする必要がある場合、それは主観的な答えです。考慮すべきことがいくつかあります。

  1. 誰かが要因を迂回して独自のデータソースを作成した場合の結果は何ですか？何も悪くない？パフォーマンスが悪い？重大なセキュリティ違反？彼らが足で自分自身を撃っているだけであるか、何も傷つけていないのであれば、おそらくあなたは彼らを止めるためにわざわざする必要はありません。
  2. それらを止めるのはどれくらい難しいですか？基になるクラスにアクセスするためにリフレクションを使用しないようにする必要がありますか？インターフェイスレイヤーを使用するだけで十分ですか？
  3. ユーザーはどの程度信頼できますか？それはあなた自身の使用のための単なる内部アプリですか、それともあなた自身のチームで使用するための内部アプリですか？それは他の何千人もの人々に出荷されていますか？小規模な内部使用アプリは気にしないかもしれません。大規模なアプリでは、本当に悪意のあるユーザーまたは無知なユーザーがいると想定する必要があり、公開する内容が非常に重要になります。ユーザーベースが拡大するにつれて、一般的にユーザビリティを改善することも重要です。
于 2012-05-08T15:07:13.570 に答える