工厂类

设计模式之创建类模式PK

|▌冷眼眸甩不掉的悲伤 提交于 2019-11-27 00:36:12
创建类模式包括: 工厂方法模式 建造者模式 抽象工厂模式 单例模式 原型模式 创建类模式能够提供对象的创建和管理职责. 其中单例模式和原型模式非常容易理解, 单例模式是要保持在内存中只有一个对象,原型模式是要求通过复制的方式产生一个新的对象,这两个不容易混淆. 工厂方法模式VS建造者模式 工厂方法模式注重的是整体对象的创建方法,而建造者模式注重的是部件构建的过程,旨在通过一步一步的精确构造创建出一个复杂的对象. 工厂方法模式和建造者模式的区别: 意图不同. 在工厂方法模式中, 我们关注的是产品的整体,无需关心产品的各部分是如何创建出来的; 但是在建造者模式中,一个具体产品的产生是依赖各个部件的产生以及装配顺序,它关注的是"由零件一步一步地组装出产品对象". 简单地说, 工厂模式是一个对象创建的粗线条应用,建造者模式则是通过细线条勾勒出一个复杂对象,关注的是产品组成部分的创建过程. 产品的复杂度不同. 工厂方法模式创建的产品一般都是单一性质产品,而建造者模式创建的则是一个复合产品,它由各个部件复合而成,不见不同产品对象当然不同. 在具体应用中如何选择呢?这取决于我们在做系统设计时的意图, 如果需要详细关注一个产品不见的生产、安装步骤,则选择建造者 ,否则选择工厂方法模式 抽象工厂模式VS建造者模式 抽象工厂模式实现对产品家族的创建, 一个产品家族是这样一系列产品:

设计模式2——Factory设计模式

孤街浪徒 提交于 2019-11-26 21:24:36
Factory工厂设计模式为创建对象提供了一种抽象,而对使用者屏蔽了对象创建的具体细节过程,工厂模式有三种:简单工厂模式,抽象工厂模式和工厂方法模式。 1. 简单工厂模式: 又叫静态工厂模式,简单工厂只包括一个抽象产品类(该类可以是接口,也可以是具体的类),所有需要的产品类都是该抽象产品类的子类。简单工厂模式中工厂为具体产品工厂,产品为抽象产品,由工厂实例创建产品实例: 一个生成圆形和矩形的图形工厂,例子如下: //图形接口 interface Shape(){ public void draw(); } //圆形 class Circle implements Shape{ public void draw(){ System.out.println(“Circle is drawing”); } } //矩形 class Rectangle implements Shape{ public void draw(){ System.out.println(“Rectangle is drawing”); } } //图形工厂 class ShapeFactory{ public static Shape createShape(String name) throws InstantiationException, IllegalAccessException,

工厂方法模式

别来无恙 提交于 2019-11-26 16:31:15
一、内容 定义一个用于创建对象的接口(工厂接口),让子类决定实例化哪一个产品类 二、角色 抽象工厂角色(Creator) 具体工厂角色(Concrere Creator) 抽象产品角色(Product) 具体产品角色(Concrete Product) 工厂方法模式相比简单工厂模式将每个具体产品都对应一个具体工厂 三、优点 每个具体产品都对应一个具体工厂类,不需要修改工厂类代码 隐藏了对象创建的实现细节 四、缺点 每增加一个具体产品类,就必须增加一个相应的具体工厂类 五、使用场景 需要生产多种、大量复杂对象的时候 需要降低耦合度的时候 当系统的产品种类需要经常扩展的时候   六、代码示例 from abc import ABCMeta,abstractmethod class PaymentFactory(metaclass=ABCMeta): @abstractmethod def create_payment(self): pass class Payment(metaclass=ABCMeta): @abstractmethod def pay(self,money): pass class Alipay(Payment): def pay(self, money): print('支付宝支付了%s元'%money) class Applepay(Payment): def

简单工厂模式

旧时模样 提交于 2019-11-26 15:44:44
又在温习设计模式咯,所以把学习的经历写下来..... 我们希望建立一个银行系统,但银行系统应具有一些业务,诸如存款、取款、转账等,通过对这些业务进行抽象,得到一个业务接口: IOperation ,该接口包含一个业务处理的抽象方法operation,如下所示: 1 interface IOperation 2 { 3 void operation(); 4 } 通过该接口实现各个银行功能类: 1 /**/ /// <summary> 2 /// 存款业务处理类 3 /// </summary> 4 class SavingBox:IOperation 5 { 6 public void operation() 7 { 8 Console.WriteLine( " You are saving! " ); 9 } 10 } 11 /**/ /// <summary> 12 /// 取款业务处理类 13 /// </summary> 14 class OutingBox : IOperation 15 { 16 public void operation() 17 { 18 Console.WriteLine( " You are outing! " ); 19 } 20 } 21 /**/ /// <summary> 22 /// 转账业务处理类 23 /// </summary>

你还在看错误的抽象工厂模式实现案例?

核能气质少年 提交于 2019-11-26 13:09:42
昨天在搜抽象工厂模式时,发现有好几篇博文讲的实现方式和我所认知的有出入,而且还看到某某教程讲的也是错误的还在搜索引擎排第一。 大家讲的简单工厂模式和工厂方法模式都是没问题的,关键到抽象工厂模式就不对了。 先从简单工厂模式和工厂方法模式复习一下,然后再看看错的是咋讲的。已经对抽象工厂模式烂熟于心的请忽略此文。 简单工厂模式: 有个一公共的产品接口,定义一些方法,各个具体的产品类都实现这个接口,然后有一个专门生产产品类实例的类被称作工厂类,专门为客户端生产产品实例,这个工厂的内部实现就是使用switch或ifelse进行逻辑判断实现的,根据客户端传递的参数不同,来决定什么时候创建什么样的具体产品,生产出不同的具体产品返回给客户端。这样,这个工厂类就集成了所有产品的创建逻辑,它变得无所不知,这也让它变成了核心。但这也成为了他的缺点,因为它将所有的逻辑集中放在一个类里,当产品接口有了新的产品实现类,工厂类需要增加代码,判断在什么时候创建该产品,就需要加入新的判断逻辑。 ShoesFactory工厂 public class ShoesFactory{ public static final String NIKE = "NIKE"; public static final String ADIDAS = "ADIDAS"; public static Shoes getShoes