C#中的工厂模式。如何确保一个对象实例只能由一个工厂类创建？

本文是小编为大家收集整理的关于C#中的工厂模式。如何确保一个对象实例只能由一个工厂类创建？的处理/解决方法，可以参考本文帮助大家快速定位并解决问题，中文翻译不准确的可切换到English标签页查看源文。

中文
English

问题描述

最近我一直在考虑保护我的一些代码.我很好奇如何确保永远不能直接创建对象，而只能通过工厂类的某种方法.假设我有一些"业务对象"类，我想确保此类的任何实例都具有有效的内部状态.为了实现这一点，我需要在创建对象之前执行一些检查，可能在其构造函数中.在我决定让这个检查成为业务逻辑的一部分之前，这一切都很好.那么，我怎样才能安排一个业务对象只能通过我的业务逻辑类中的某些方法而不是直接创建呢?使用 C++ 的好老"朋友"关键字的第一个自然愿望将在 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 实例，而无需检查输入.我想完全排除这种技术可能性.

那么，社区对此有何看法?

推荐答案

看起来你只是想在创建对象之前运行一些业务逻辑 - 那么你为什么不在"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);

本文地址：https://www.itbaoku.cn/post/627556.html

百度翻译此文有道翻译此文

问题描述

Recently I've been thinking about securing some of my code. I'm curious how one could make sure an object can never be created directly, but only via some method of a factory class. Let us say I have some "business object" class and I want to make sure any instance of this class will have a valid internal state. In order to achieve this I will need to perform some check before creating an object, probably in its constructor. This is all okay until I decide I want to make this check be a part of the business logic. So, how can I arrange for a business object to be creatable only through some method in my business logic class but never directly? The first natural desire to use a good old "friend" keyword of C++ will fall short with C#. So we need other options...

Let's try some example:

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;
    }
}

It's all okay until you remember you can still create MyBusinessObjectClass instance directly, without checking the input. I would like to exclude that technical possibility altogether.

So, what does the community think about this?

推荐答案

Looks like you just want to run some business logic before creating the object - so why dont you just create a static method inside the "BusinessClass" that does all the dirty "myProperty" checking work, and make the constructor private?

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;
    }
}

Calling it would be pretty straightforward:

BusinessClass objBusiness = BusinessClass.CreateObject(someProperty);

上一篇：什么时候应该使用单子模式而不是静态类？

下一篇：除了GOF单子模式，还有什么可行的替代方案吗？