Question

我和老师争论这是否是工厂模式。我可以让你的一些人输入吗？

public class UrlFactory {
    private static boolean testMode;
    private static long testDate;

    public static URLConnection fetchConnection(String url) 
                                              throws IOException
    {
        URL address = new URL(url);

        if(testMode)
            return new MockURLConnection(address, testDate);
        return address.openConnection();
    }

    public static void SetTestMode(long testDate)
    {
        UrlFactory.testMode = true;
        UrlFactory.testDate = testDate;
    }

    public static void UnSetTestMode()
    {
        UrlFactory.testMode = false;
    }
}

Answer 1

它看起来在结构上类似于工厂，但我会说它忽略了工厂模式的要点。理想情况下，工厂是可实例化和可重写的（例如，具有用于创建的虚拟方法）。我推荐一种设计，其中UrlFactory是一个非静态类，具有虚拟fetchConnection方法。然后，您可以使用派生类MockUrlFactory覆盖fetchConnection以返回MockURLConnection。

示例：

public class UrlFactory {
    public URLConnection fetchConnection(String url)
        throws IOException {
        URL address = new URL(url);
        return address.openConnection();
    }
}

public class MockUrlFactory extends UrlFactory {
    private long testDate;

    public MockUrlFactory(long testDate) {
        this.testDate = testDate;
    }

    public URLConnection fetchConnection(String url)
        throws IOException {
        URL address = new URL(url);
        return new MockURLConnection(address, testDate);
    }
}

Answer 2

正如bobbymcr指出的那样，肯定有更好的，更面向对象的方式来实现工厂模式。

但是，这并不排除您的示例本身就是工厂模式的示例。

请记住，术语“设计模式”本身有点难以定义。这意味着大多数“设计模式”也很难用具体的术语来定义。它们通常以非常笼统的术语表示，其中的实现细节留给开发人员。实际上，这种通用性已经包含在设计模式的定义中：

这种语言的元素是称为模式的实体。每个模式都描述了在我们的环境中反复出现的问题，然后描述了该问题解决方案的核心，以这种方式使您可以使用此解决方案一百万次， 以同样的方式做两次 。

定义中的松散很多次使得设计模式的讨论具有准宗教性，并且，与任何宗教一样，有许多狂热者。然而，即使你不完全坚持信仰，我遇到的大多数狂热者都会提出值得考虑的要点。

所有这一切，我的宗教立场与bobbymcr的相同。工厂方法用于覆盖子类。

这不是工厂模式吗？

2 个答案: