C++常见设计模式之工厂模式(简单工厂模式、工厂方法模式、抽象工厂模式)

1、工厂模式属于创建型模式 ,大致分为3类:简单工厂模式 、工厂方法模式、 抽象工厂模式。

2、简单工厂模式:需要在工厂类中做出判断,从而创造出相应的产品,当增加新产品时,就需要修改工厂类。

//有一家生产处理器核的厂家,它只有一个工厂(1个类),能够生产两种单核处理器核(2个类,两种处理器某些共同特点,1个父类)
//客户需要什么样的处理器,一定要显示的告诉生产工厂。

enum CTYPE{TYPEA ,TYPEB};

class Product
{
public:
	virtual void Show() = 0;
};

//生产A类型
class ProductA :public Product
{
public:
	void Show()
	{
		cout<<"生产A"<<endl;
	}
};

//生产B类型

class ProductB :public Product
{
public:
	void Show()
	{
		cout<<"生产B"<<endl;
	}
};

class Factory
{
public:
	Product *Create(enum CTYPE type)
	{
		if(type == TYPEA)
		    return new ProductA();
		else if(type == TYPEB)
		    return new ProductB();
		else
		    return NULL;
	}
};

int main()
{
	Factory p;
	p.Create(TYPEA)->Show();

	p.Create(TYPEB)->Show();

}

在这里插入图片描述

简单工厂模式的缺点:增加新的核类型时,就需要修改工厂类 这就违反了模式设计的开放封闭原则: 软件实体(类,模块,函数)可以扩展,但是不能够修改。于是工厂方法模式出现了。

3、工厂方法模式:定义一个创建对象的接口,随后让子类自己选择要实例化的工厂类,然后将实例化的过程移动到子类中进行。听起来比较抽象,接着刚才的例子,这家生产处理器核的厂家赚了不少钱,于是决定在建造一个工厂专门用来生产B型号产品。原来的用来专门生产A。这时客户要做的是找好工厂,比如要A型号的产品,就去找A工厂,否则就去B工厂。不需要再告诉工厂具体要什么型号的产品了。每一个具体的工厂类只生产一种产品。

//一个工厂类父类,两个具体哪种型号的生产工厂类继承父类,产品同样也是一个父类,每种产品继承父类,共6个类。
lass Product
{
public:
	virtual void Show() = 0;
};

//生产A类型

class ProductA :public Product
{
public:
	void Show()
	{
		cout<<"生产A"<<endl;
	}
};

//生产B类型

class ProductB :public Product
{
public:
	void Show()
	{
		cout<<"生产B"<<endl;
	}
};

class Factory
{
public:
	virtual Product* create() = 0;
};

class FactoryA :public Factory
{
	ProductA *create(){
		return new ProductA;
	}
};

class FactoryB :public Factory
{
	ProductB *create(){
		return new ProductB;
	}
};

int main()
{
	Factory *p1 = new FactoryA;
	//p1 父类指针指向工厂A 调用工厂A中的创造 返回产品A对象 产品A对象调用show函数
	p1->create()->Show();

	Factory *p2 = new FactoryB;
	p2->create()->Show();

	return 0;
}

工厂方法模式也有缺点, 每增加一种产品,就需要增加一个对象的工厂。如果这家公司发展迅速,推出许多新产品,那么就要开设相应新工厂。在C++的实现里,就是要定义一个个的工厂类,显然,相比简单工厂模式,工厂方法模式需要更多类的定义。

4、既然有了上面两种方法,为什么还要有抽象工厂模式呢?他又有什么作用?还是这个例子,这家公司技术不断进步,不仅可以生产单核处理器,也能生产多核处理器。现在简单工厂模式和工厂方法模式都鞭长莫及。抽象工厂模式登场了。它的定义为提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。

这家公司还是开设两个工厂,一个专门用来生产A型号的单核多核处理器,而另一个工厂专门用来生产B型号的单核多核处理器。

//单核
class Product
{
public:
	virtual void Show() = 0;
};

//生产A类型单核

class ProductA :public Product
{
public:
	void Show()
	{
		cout<<"生产单核A"<<endl;
	}
};

//生产B类型单核

class ProductB :public Product
{
public:
	void Show()
	{
		cout<<"生产单核B"<<endl;
	}
};

//多核
class MutiplyProduct
{
public:
	virtual void Show() = 0;
};

//生产A类型多核
class MutiplyProductA :public MutiplyProduct
{
public:
	void Show()
	{
		cout<<"生产多核A"<<endl;
	}
};

//生产B类型多核

class MutiplyProductB :public MutiplyProduct
{
public:
	void Show()
	{
		cout<<"生产多核B"<<endl;
	}
};

//工厂
class Factory
{
public:
	virtual Product* create() = 0;
	virtual MutiplyProduct* Mutiplycreate() = 0;
};

//工厂A专门生产A类型产品
class FactoryA :public Factory
{
	ProductA *create(){
		return new ProductA;
	}

	MutiplyProductA *Mutiplycreate(){
		return new MutiplyProductA;
	}
};

//工厂B专门生产B类型产品
class FactoryB :public Factory
{
	ProductB *create(){
		return new ProductB;
	}
	MutiplyProductB *Mutiplycreate(){
		return new MutiplyProductB;
	}
};

int main()
{
	Factory* p1 = new FactoryA; //父类指针指向工厂A
	p1->create()->Show();  //工厂A生产A类型的哪种处理器
	p1->Mutiplycreate()->Show();


	Factory* p2 = new FactoryB;
	p2->create()->Show();
	p2->Mutiplycreate()->Show();
}

在这里插入图片描述
工厂方法模式优势在于后期的过程中可以增加产品的种类,适用于结构比较单一的场所中,为同一类的产品提供创建的接口,而抽象工厂模式则适用于产品种类比较多的场所,当有多个抽象类的产品类型时,抽象工厂就派上了用场。

举个完整的例子:
你想吃牛肉干,你去到一家店里买到了,很开心,可是当你走的时候,你又想喝芋泥啵啵奶茶,但是这家店太小了只有一个房间,只能卖牛肉干。没有位置放下其它吃的了,如果想要在这家店里买到就需要扩建,很麻烦 。(简单工厂)

那你接着又去了另一家店,想要买喝的,这家店有很多个房间,而且每一个房间里都只有一种口味的吃的或者喝的,你买完了一杯的芋泥啵啵奶茶,然后走的时候又想来一杯奥利奥厚乳奶茶,你转了一圈发现没有卖奥利奥厚乳的房间,你就去问门口的管理所有房间的人,管理者说没问题 ,我们这里有很多多余的地方,建造一个房间实现了你想要的奶茶。你买了一杯满意的离开。(工厂方法)

第二天,你又来的这家店,但是你这次也要帮你的朋友买东西,你的朋友想要n种不同口味的奶茶 ,还想要n种口味的薯片,你跑了很多个房间很累。然后那天你离开的时候就跟管理者说 如果你能把所有卖奶茶的集中到一起,所有卖薯片的集中到一起, 所有同类型产品不同口味的都集中到一起, 这样多方便顾客购买呀,管理者觉得你说的很有道理 ,于是 … … (抽象工厂)

部分内容参考于:https://blog.csdn.net/wuzhekai1985/article/details/6660462

<think>好的,我现在需要帮助用户解决关于Dify循环实现的问题。首先,我需要明确用户的具体需求。他们提到“dify 循环实现”或“dify 如何处理循环”,但Dify本身可能没有直接称为“循环”的功能,所以需要结合现有文档中的信息来推断可能的解决方案。 根据用户提供的引用内容,Dify工作流中有迭代节点[^1]。这可能类似于编程中的循环结构,用于重复执行某个任务。例如,在处理列表数据或需要多次执行同一操作时,迭代节点可以派上用场。我需要详细解释迭代节点的配置和使用步骤,确保用户能够理解如何设置循环次数或遍历数据集。 另外,用户可能对如何处理循环中的错误或性能问题感兴趣。引用[2]提到在Dify中处理PEM文件的问题,这可能涉及在循环中正确处理数据格式,避免错误积累。需要提醒用户在循环中注意错误处理和资源管理,确保每次迭代的稳定性。 引用[3]中的例子展示了如何结合FastAPI和Selenium进行实时监控并生成GIF,这可能涉及循环截取浏览器内容。虽然Dify本身可能不直接控制这类循环,但可以通过外部脚本或定时任务触发工作流,模拟循环执行。这部分需要说明如何将外部循环机制与Dify结合使用。 接下来,我需要组织回答结构。首先介绍迭代节点的基本概念和配置步骤,然后讨论循环中的数据处理和错误处理,最后补充外部触发循环的方法。同时,生成相关问题以帮助用户进一步探索,比如优化循环性能或处理复杂数据结构。 需要确保回答符合格式要求,使用正确的中文表达,行内公式用$...$,独立公式用$$...$$,但当前问题不涉及数学公式,所以可能不需要使用。同时,引用标识要自然地添加到相关段落末尾,如、[^2]、[^3]。 最后,检查是否有遗漏点,比如Dify的其他循环相关功能或用户可能遇到的常见问题,确保回答全面且易于理解。</think>在Dify中处理循环逻辑主要通过**迭代节点**实现,以下是具体实现方式和应用场景的解析: ### 一、Dify循环实现机制 Dify通过**工作流设计器**中的迭代节点处理循环需求,其核心原理类似编程中的`for循环`。迭代节点可遍历以下数据类型: - 数组列表:`["A","B","C"]` - 字典集合:`{"key1":"value1", "key2":"value2"}` - 数值范围:通过`range()`函数生成序列 配置示例: ```python # 模拟迭代节点的数据输入 input_data = { "dataset": [1,2,3,4,5], "process_logic": "item * 2" # 对每个元素执行乘以2的操作 } ``` ### 二、迭代节点的关键配置步骤 1. **数据源绑定**:将数组/字典类型变量连接到迭代节点的输入端口 2. **循环变量命名**:设定当前元素的变量名(默认为`item`) 3. **子流程设计**:在迭代节点内部构建需要重复执行的逻辑模块 4. **结果聚合**:通过`outputs`收集所有迭代结果,支持数组或对象格式 $$ \text{总耗时} = \sum_{i=1}^{n}(单次迭代时间_i) + 系统开销 $$ ### 三、循环中的特殊处理 1. **错误中断控制**: - 启用`continueOnError`参数可跳过失败迭代 - 通过`try-catch`模块包裹敏感操作 2. **并行优化**: ```python # 伪代码示例 Parallel.forEach(dataset, lambda item: process(item)) ``` 3. **结果过滤**: ```python filtered = filter(lambda x: x%2==0, processed_results) ``` ### 四、应用场景案例 1. **批量文件处理**:遍历存储桶中的文件列表进行格式转换 2. **数据清洗**:对数据库查询结果集进行逐条校验 3. **API轮询**:定时循环调用第三方接口直到满足特定条件
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值