工厂方法模式

描述:定义一个用于创建对象的接口,让子类决定实例化哪一个类。Factory Method使一个类实例化延迟到其子类

接着上一篇简单工厂模式来讲,可以看到新增了抽象工厂角色。

关键点

  1. 抽象工厂角色:这是工厂方法模式的核心。是具体工厂角色必须实现的接口或者必须继承的父类,在java中由接口或者抽象类来实现。
  2. 具体工厂角色:含有一定的商业逻辑和判断逻辑,在java中往往由一个具体类实现。
  3. 抽象产品角色:一般是具体产品继承的父类或者实现的接口,在java中由接口或者抽象类来实现。
  4. 具体产品角色:工厂类所创建的对象就是此角色的实例,在java中有一个具体类实现。

 情景还是上一篇的客户购车:

     假设此时做了一些更改,4s店有两个生产部门,一个部门专门生产宝马汽车,另一个专门生产奥迪汽车。

     原来的工厂角色变成了两个,一个是抽象工厂角色(接口),一个是具体工厂角色。具体工厂角色又分了两个部门(奥迪,宝马)。简单来说就是:CarFactory变成了接口,它有一个生产汽车的方法,我们分别创建具体工厂BaomaFactory与AodiFactory来实现这个接口,这样一来就实现了两个部门生产不同的汽车。

    也就是上面所说使一个类实例化延迟到其子类。


看代码比较容易懂:

汽车接口及其实现宝马汽车、奥迪汽车不变

package com.zlfan.methodfactory;
/*
 * 汽车接口
 */
public interface Car {
	
	void run();
	
}
package com.zlfan.methodfactory;
/*
 * 宝马汽车
 */
public class BaomaCar implements Car {

	@Override
	public void run() {
		System.out.println("宝马跑起来了。");
	}

}
package com.zlfan.methodfactory;
/*
 * 奥迪汽车
 */
public class AodiCar implements Car {

	@Override
	public void run() {
		System.out.println("奥迪跑起来了。");
	}

}

4s店此时变成了CarFactory接口

package com.zlfan.methodfactory;
/*
 * 汽车工厂接口
 */
public interface CarFactory {
	Car produceCar();
}

两个部门实现此接口

package com.zlfan.methodfactory;

public class BaomaFactory implements CarFactory {

	@Override
	public Car produceCar() {
		// TODO Auto-generated method stub
		return new BaomaCar();
	}

}
package com.zlfan.methodfactory;

public class AodiFactory implements CarFactory {

	@Override
	public Car produceCar() {
		// TODO Auto-generated method stub
		return new AodiCar();
	}

}

 

最终客户购买的时候,就相当于到4s店具体哪个部门购车

package com.zlfan.methodfactory;

public class Customer {

	public static void main(String[] args) {
		// TODO Auto-generated method stub
		CarFactory baoma = new BaomaFactory();
		baoma.produceCar().run();
		
		CarFactory aodi = new AodiFactory();
		aodi.produceCar().run();
	}

}

该工厂方法模式的结构是这样的:

 

上一篇讲到了开闭原则,此时客户要购买店里没有的奔驰车型,我们该如何拓展4s店呢?

需要新增一个奔驰生产部(BenchiFactory)实现CarFatory接口,另外新增BenchiCar实现Car接口,在BenchiFactory中就可以创建奔驰车对象BenchiCar了。

package com.zlfan.methodfactory;

public class BenchiCar implements Car  {
	@Override
	public void run() {
		// TODO Auto-generated method stub
		System.out.println("奔驰跑起来了。");
	}	
}
package com.zlfan.methodfactory;

public class BenchiFactory implements CarFactory {

	@Override
	public Car produceCar() {
		// TODO Auto-generated method stub
		return new BenchiCar();
	}

}

这样,我们就在不改变已有的代码的基础上,扩展了变化。

 

工厂方法模式的优缺点

优点:更符合开闭原则,新增一种产品,只需要增加相应的具体产品类和相应的工厂子类即可。

           符合单一职责原则,每个具体工厂类只负责创建对应的产品。

缺点:在增加一个新产品的时候,需要增加一个产品类和具体的子工厂类,给系统,增加负担的同时,每个工厂生产一种

           产品,太过单一。

 

工厂方法模式的适用场景

  • 当一个类不知道它所必须创建的对象的类的时候。
  • 当一个类希望由它的子类来指定它所创建的对象的时候。
  • 当类将创建对象的职责委托给多个帮助子类中的某一个,并且你希望将哪一个帮助子类使代理者这一信息局部化的时候。

 工厂方法模式足以应付我们可能遇到的大部分业务需求。但是当产品种类非常多的时候怎么办呢?

下一篇抽象工厂

【从高压输电线的架空地线中汲取电能】一个25千瓦受控电源从735千伏线路的架空地线中汲取电能的SimPowerSystems模型(Simulink仿真实现)内容概要:本文介绍了一个基于SimPowerSystems的Simulink仿真模型,用于模拟从735千伏高压输电线的架空地线中汲取25千瓦电能的受控电源系统。该模型聚焦于高压输电线路中架空地线的能量回收技术,通过仿真手段实现对电能采集过程的建模与控制策略验证,体现了电力系统中新型能源获取方式的技术可行性与工程应用潜力。文中还提及该资源属于一系列电力系统仿真研究的一部分,涵盖微电网、储能优化、碳流追踪、鲁棒调度等多个前沿方向,配套提供Matlab/Simulink代码及网盘资料链接,便于科研人员复现与拓展研究。; 适合人群:具备电力系统基础知识、熟悉Matlab/Simulink仿真环境,从事电力工程、能源回收或智能电网相关研究的科研人员及研究生;有一定编程与建模仿真经验的高年级本科生或工程技术人员。; 使用场景及目标:①研究高压输电线路中架空地线的能量回收机制与建模方法;②掌握基于Simulink的电力系统仿真技术,特别是受控电源与电网交互的动态特性分析;③为开展能源 harvesting、分布式供能、电力电子变换器控制等相关课题提供参考模型与技术支撑; 阅读建议:建议结合提供的仿真模型文件进行实操演练,重点理解系统结构设计、参数设置与控制逻辑实现;同时可延伸学习文档中提到的其他电力系统优化与仿真案例,以拓宽研究视野和技术积累。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值