简单工厂模式

简单工厂模式:
    简单工厂模式的实质是由一个工厂类根据传入的参数,动态决定应该创建哪一个产品类的实例。工厂封装了对象的创建过程。
简单工厂模式的两个重要的功能:
    (1)定义创建对象的接口,封装了对象的创建;
    (2)使得具体化类的工作延迟到了子类中。

工厂类:
    负责实现创建所有实例的内部逻辑。根据给定的参数创建对应的对象。

抽象产品(抽象基类):
    简单工厂模式所创建的所有对象的父类,它负责描述所有实例所共有的公共接口

具体产品(产品的具体类):
    对应产品的具体实现。        

                                                                                                                                               
简单工厂模式的使用场景:
    工厂类负责创建的对象比较少,客户只知道传入参数给工厂类,就能产生相应的对象,不关心如何来创建。且不会随意更改工厂中的内部逻辑,即添加一种水果类的实例方法,这样会破坏了工厂的开放封闭原则。

优点:工厂类是整个模式的关键.包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象.通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的.明确了各自的职责和权利,有利于整个软件体系结构的优化。

缺点:由于工厂类集中了所有实例的创建逻辑,违反了高内聚责任分配原则,将全部创建逻辑集中到了一个工厂类中;它所能创建的类只能是事先考虑到的,如果需要添加新的类,则就需要改变工厂类了。

当系统中的具体产品类不断增多时候,可能会出现要求工厂类根据不同条件创建不同实例的需求.这种对条件的判断和对具体产品类型的判断交错在一起,很难避免模块功能的蔓延,对系统的维护和扩展非常不利;

例如:
用一个工厂来生产水果,那么要定义一个水果抽象的基类、一个工厂和一些水果的具体实现的类。

#include < iostream>
#include <string>
#include <memory>

class Fruit      //水果类
{
public:
	Fruit(std::string name):mname(name){}
	virtual void operation () = 0;    //纯虚函数
	virtual ~Fruit(){}   // 虚析构函数,防止内存泄漏

protected:
	std::string mname;
};

class Apple:public Fruit   //苹果类
{
public:
	Apple(std::string name):Fruit(name){}
	void operation()
	{
		std::cout<<"this is "<<mname<<std::endl;
	}
};
class Banane:public Fruit     //香蕉类
{
public:
	Banane(std::string name):Fruit(name){}
	void operation()
	{
		std::cout<<"this is "<<mname<<std::endl;
	}
};

class Factory      //工厂用来产生具体的产品
{
public:
	Fruit* createProduct(int flag)//给工厂传入相应的参数,生产对应的水果。
	{
		switch(flag)   
		{
		case 1:   
			return new Apple("apple"); //创建一个苹果类的对象
			break;
		case 2:
			return new Banane("banane");//创建一个香蕉类的对象
			break;
		default:
			std::cout<<"factory does not product this product"<<std::endl;
			break;
		}
	}
};

int main()
{
	Factory f;     //定义一个工厂对象

   //对象调用方法,根据参数产生具体的产品,基类产品的指针可以指向派生类具体产品的对象
	Fruit* pf = f.createProduct(1);  

	pf->operation();//调用派生类中的方法

	delete pf;
	return 0;
}


 

AI 代码审查Review工具 是一个旨在自动化代码审查流程的工具。它通过集成版本控制系统(如 GitHub 和 GitLab)的 Webhook,利用大型语言模型(LLM)对代码变更进行分析,并将审查意见反馈到相应的 Pull Request 或 Merge Request 中。此外,它还支持将审查结果通知到企业微信等通讯工具。 一个基于 LLM 的自动化代码审查助手。通过 GitHub/GitLab Webhook 监听 PR/MR 变更,调用 AI 分析代码,并将审查意见自动评论到 PR/MR,同时支持多种通知渠道。 主要功能 多平台支持: 集成 GitHub 和 GitLab Webhook,监听 Pull Request / Merge Request 事件。 智能审查模式: 详细审查 (/github_webhook, /gitlab_webhook): AI 对每个变更文件进行分析,旨在找出具体问题。审查意见会以结构化的形式(例如,定位到特定代码行、问题分、严重程度、分析和建议)逐条评论到 PR/MR。AI 模型会输出 JSON 格式的分析结果,系统再将其转换为多条独立的评论。 通用审查 (/github_webhook_general, /gitlab_webhook_general): AI 对每个变更文件进行整体性分析,并为每个文件生成一个 Markdown 格式的总结性评论。 自动化流程: 自动将 AI 审查意见(详细模式下为多条,通用模式下为每个文件一条)发布到 PR/MR。 在所有文件审查完毕后,自动在 PR/MR 中发布一条总结性评论。 即便 AI 未发现任何值得报告的问题,也会发布相应的友好提示和总结评论。 异步处理审查任务,快速响应 Webhook。 通过 Redis 防止对同一 Commit 的重复审查。 灵活配置: 通过环境变量设置基
【直流微电网】径向直流微电网的状态空间建模与线性化:一种耦合DC-DC变换器状态空间平均模型的方法 (Matlab代码实现)内容概要:本文介绍了径向直流微电网的状态空间建模与线性化方法,重点提出了一种基于耦合DC-DC变换器的状态空间平均模型的建模策略。该方法通过数学建模手段对直流微电网系统进行精确的状态空间描述,并对其进行线性化处理,以便于系统稳定性分析与控制器设计。文中结合Matlab代码实现,展示了建模与仿真过程,有助于研究人员理解和复现相关技术,推动直流微电网系统的动态性能研究与工程应用。; 适合人群:具备电力电子、电力系统或自动化等相关背景,熟悉Matlab/Simulink仿真工具,从事新能源、微电网或智能电网研究的研究生、科研人员及工程技术人员。; 使用场景及目标:①掌握直流微电网的动态建模方法;②学习DC-DC变换器在耦合条件下的状态空间平均建模技巧;③实现系统的线性化分析并支持后续控制器设计(如电压稳定控制、功率分配等);④为科研论文撰写、项目仿真验证提供技术支持与代码参考。; 阅读建议:建议读者结合Matlab代码逐步实践建模流程,重点关注状态变量选取、平均化处理和线性化推导过程,同时可扩展应用于更复杂的直流微电网拓扑结构中,提升系统分析与设计能力。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值