Design patterns 设计模式语义：示例中给出的操作是否可以归类为工厂方法？

描述没有代码的问题：

interface Product { ... }
class ConcreteProductA { ... }
class ConcreteProductB { ... }

class ProductHolder
{
    private Product foo;

    /*
    * May return an instance of either ConcreteProductA or ConcreteProductB
    * Sets foo null, for attempting to mimic a composition relationship to holder, foo being moved into another composition relationship
    */
    public Product getProduct() {
        Product reference = foo;
        foo = null;
        return reference;
    }

    public void setProduct(Product foo) {
        this.foo = foo;
    }
}

interface Creator { public Product createProduct(); }

class ConcreteCreatorA implements Creator
{
    @Override
    public Product createProduct(ProductHolder holder) {
        return holder.getProduct();
    }
}

如果类的操作（以其他方式满足工厂方法-模式的结构）返回现有对象引用的副本，该引用由另一个对象的操作获取，并由其已知类型使用，而不是实例化新对象，那么它可以归类为工厂方法吗

此外，如果被视为非工厂方法；创建ConcreteProduct新实例的过程是否发生在ConcreteCreator中，这是否重要？（考虑到在JAVA中，您总是返回一个引用，因此唯一实际的区别是我们创建一个新实例而不是使用一个现有实例——但这是否会影响我们是否有“工厂方法”

JAVA中的一个简单示例：

interface Product { ... }
class ConcreteProductA { ... }
class ConcreteProductB { ... }

class ProductHolder
{
    private Product foo;

    /*
    * May return an instance of either ConcreteProductA or ConcreteProductB
    * Sets foo null, for attempting to mimic a composition relationship to holder, foo being moved into another composition relationship
    */
    public Product getProduct() {
        Product reference = foo;
        foo = null;
        return reference;
    }

    public void setProduct(Product foo) {
        this.foo = foo;
    }
}

interface Creator { public Product createProduct(); }

class ConcreteCreatorA implements Creator
{
    @Override
    public Product createProduct(ProductHolder holder) {
        return holder.getProduct();
    }
}

Edit:注意，我故意不检查方法是否返回null，这与问题是否相关

---

（我的）论点：

interface Product { ... }
class ConcreteProductA { ... }
class ConcreteProductB { ... }

class ProductHolder
{
    private Product foo;

    /*
    * May return an instance of either ConcreteProductA or ConcreteProductB
    * Sets foo null, for attempting to mimic a composition relationship to holder, foo being moved into another composition relationship
    */
    public Product getProduct() {
        Product reference = foo;
        foo = null;
        return reference;
    }

    public void setProduct(Product foo) {
        this.foo = foo;
    }
}

interface Creator { public Product createProduct(); }

class ConcreteCreatorA implements Creator
{
    @Override
    public Product createProduct(ProductHolder holder) {
        return holder.getProduct();
    }
}

• （最重要的是）它满足了GoF：设计模式——本书的工厂方法——零件的“适用性”——第1节：

（使用工厂方法-模式，当）…CreatorClass事先不知道实例化对象必须来自哪个ProductClass时。）

[可能是一组不正确的单词；我使用的是翻译版本。]

• 它确实分配内存，用于保存对所选对象的引用
• 它被类型化为创建者类所知的类型
• 它是在ConcreteCreator-class中定义的（参考GoF:Design Patterns-book的UML图）

---

（我的）反对论据：

interface Product { ... }
class ConcreteProductA { ... }
class ConcreteProductB { ... }

class ProductHolder
{
    private Product foo;

    /*
    * May return an instance of either ConcreteProductA or ConcreteProductB
    * Sets foo null, for attempting to mimic a composition relationship to holder, foo being moved into another composition relationship
    */
    public Product getProduct() {
        Product reference = foo;
        foo = null;
        return reference;
    }

    public void setProduct(Product foo) {
        this.foo = foo;
    }
}

interface Creator { public Product createProduct(); }

class ConcreteCreatorA implements Creator
{
    @Override
    public Product createProduct(ProductHolder holder) {
        return holder.getProduct();
    }
}

• 它使用现有对象，因此不创建新实例。（从语义上看，这是必要的吗？）
• 它复制一个特定的对象，而不是一个特定的类。（相对于新构造的实例，给定实例可能具有现有的更改状态）

---

相关但独立的问题帖子：

interface Product { ... }
class ConcreteProductA { ... }
class ConcreteProductB { ... }

class ProductHolder
{
    private Product foo;

    /*
    * May return an instance of either ConcreteProductA or ConcreteProductB
    * Sets foo null, for attempting to mimic a composition relationship to holder, foo being moved into another composition relationship
    */
    public Product getProduct() {
        Product reference = foo;
        foo = null;
        return reference;
    }

    public void setProduct(Product foo) {
        this.foo = foo;
    }
}

interface Creator { public Product createProduct(); }

class ConcreteCreatorA implements Creator
{
    @Override
    public Product createProduct(ProductHolder holder) {
        return holder.getProduct();
    }
}

---

对他/她的问题的一般回答：Singleton Factory阅读代码我假设会有一个

ConcreteCreatorB

，

C

，等等。至少其中一些会真正更新对象，而不是重用现有对象

---

所以，我想只要这是真的，它仍然是一种工厂方法。否则，它可能不是一个-我看不出让它看起来像一个有什么意义，给它命名，比如

createProduct（）

和

Creator

对我来说，任何返回要使用的对象（不是实体）的东西都可以被视为工厂，即使对象是新的或旧的。但与建筑商不同。我唯一的问题是，如何设计

工厂

类。然而，它们的“新的升级”（实例化）对象并不是。这个问题假定所有这些子类都将使用相同的重用方法。（如果名称似乎有误导性，我很抱歉，但它们是为了使此参考尽可能容易地与其他工厂方法案例进行比较。）我不确定我是否理解你的观点。对我来说，

createProduct（）

本质上传达了一种想法，即将返回一个全新的对象。如果它的所有实现只是将现有的

产品

伪装成新的，那么它就不再值得称为工厂方法了。用于获取现有

产品的对象是否是现有对象，是为环境创建的对象还是
创建者本身都无关紧要，如果这是您的意思的话。确切地说，“它的所有实现只是将现有
产品
伪装成新的”。尽管这个答案与芬迪早些时候对这个问题的评论相矛盾；所以我会看看是否有新的观点出现。谢谢你们两位！：）