标签: factory

工厂和抽象工厂模式之间的基本区别是什么？

什么时候在对象中使用工厂方法而不是Factory类是个好主意？

我正在从网站上阅读设计模式

在那里我读到了有关工厂,工厂方法和抽象工厂的信息,但它们很混乱,我对定义并不清楚.根据定义

Factory - 创建对象而不将实例化逻辑暴露给客户端,并通过公共接口引用新创建的对象.是Factory Method的简化版本

工厂方法 - 定义用于创建对象的接口,但让子类决定实例化哪个类,并通过公共接口引用新创建的对象.

抽象工厂 - 提供用于创建相关对象族的界面,而无需明确指定其类.

我还查看了关于抽象工厂与工厂方法的其他stackoverflow线程,但是那里绘制的UML图使我的理解更加糟糕.

有谁能告诉我

1. 这三种模式如何相互不同？
2. 什么时候用哪个？
3. 如果可能的话,任何与这些模式相关的java示例？

我有一个文件:Base.h

class Base;
class DerivedA : public Base;
class DerivedB : public Base;

/*etc...*/

和另一个文件:BaseFactory.h

#include "Base.h"

class BaseFactory
{
public:
  BaseFactory(const string &sClassName){msClassName = sClassName;};

  Base * Create()
  {
    if(msClassName == "DerivedA")
    {
      return new DerivedA();
    }
    else if(msClassName == "DerivedB")
    {
      return new DerivedB();
    }
    else if(/*etc...*/)
    {
      /*etc...*/
    }
  };
private:
  string msClassName;
};

/*etc.*/

有没有办法以某种方式将此字符串转换为实际类型(类),以便BaseFactory不必知道所有可能的Derived类,并为每个类都有if()？我可以用这个字符串生成一个类吗？

我认为这可以通过Reflection在C#中完成.C++中有类似的东西吗？

我想大多数类似工厂的方法都是从这开始的create.但为什么他们被称为" 创造 "？为什么不" 制造 "," 生产 "," 建立 "," 生成 "或其他什么？这只是品味问题吗？会议？或者"创造"中有特殊含义吗？

createURI(...) 
makeURI(...)
produceURI(...)
buildURI(...)
generateURI(...)

你会选择哪一个？为什么？

我花了太多时间在连接一些JNDI工厂bean时试图找出一些错误.结果问题是,而不是......

<bean id="someId" class="org.springframework.jndi.JndiObjectFactoryBean">
  <property name="jndiName" value="java:comp/env/jdbc/loc"/>
</bean>

我其实写了这个......

<bean id="someId" class="org.springframework.jndi.JndiObjectFactoryBean">
  <property name="jndiName" value="jdbc/loc"/>
</bean>

我推断java:comp/env /可能引用了一些环境变量,并最终使我的上下文文件被查看.唯一的区别是java:comp/env /.从专家的口中,这是做什么的？

如果没有值中的java:comp/env前缀,我将收到一条错误,指出"Name jdbc未绑定在此Context中".

AngularJS在其文档中明确指出服务是单身人士:

AngularJS services are singletons

与直觉相反,module.factory也返回一个Singleton实例.

鉴于非单例服务有很多用例,实现工厂方法返回服务实例的最佳方法是什么,这样每次ExampleService声明一个依赖项时,它都会被一个不同的实例所满足ExampleService？

最近我一直在考虑保护我的一些代码.我很好奇如何确保永远不能直接创建对象,而只能通过工厂类的某种方法创建.让我们说我有一些"业务对象"类,我想确保这个类的任何实例都有一个有效的内部状态.为了实现这一点,我需要在创建对象之前执行一些检查,可能在其构造函数中.这一切都没问题,直到我决定将此检查作为业务逻辑的一部分.那么,我如何安排业务对象只能通过我的业务逻辑类中的某种方法创建,但从不直接？使用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实例,而无需检查输入.我想完全排除这种技术可能性.

那么,社区对此有何看法？

我期待在本地开发只有一个硬编码的JSON文件.我的JSON文件如下(放入JSON验证器时有效):

{
    "contentItem": [
            {
            "contentID" : "1", 
            "contentVideo" : "file.mov",
            "contentThumbnail" : "url.jpg",
            "contentRating" : "5",
            "contentTitle" : "Guitar Lessons",
            "username" : "Username", 
            "realname" : "Real name",
            "contentTags" : [
                { "tag" : "Guitar"},
                { "tag" : "Intermediate"},
                { "tag" : "Chords"}
            ],      
            "contentAbout" : "Learn how to play guitar!",
            "contentTime" : [
                { "" : "", "" : "", "" : "", "" : ""},
                { "" : "", "" : "", "" : "", "" : ""} …

如何构造将参数直接传递给自己的类的对象？

像这样的东西:

Dim this_employee as Employee
Set this_employee = new Employee(name:="Johnny", age:=69)

无法做到这一点非常烦人,你最终会得到一些肮脏的解决方案来解决这个问题.