工厂模式

工厂模式 什么是设计模式？ 设计模式就是经过前人无数次的实践总结出的，设计过程中可以反复使用的、可以解决特定问题的设计方法，也就是一套被反复使用，多数人知晓的，经过分类编目的，代码设计经验的总结 其目的是：使用设计模式是为了可重用代码，让代码更容易被他人理解，保证代码的可靠性。 工厂模式的概念 实列化对象，用工厂方法代替new操作 工厂模式包括工厂方法模式和抽象工厂模式 抽象工厂模式是工厂方法模式的扩展 工厂模式的意图 定义一个接口来创建对象，但是让子类决定哪些类需要被实例化 工厂方法把实例化的工作推迟到子类中去实现 工厂模式的应用场景 有一组类似的对象需要创建 在编码时不能预见需要创建那种类的实例 系统需要考虑扩展性，不应依赖于产品类实例如何被创建，组合和表达细节 工厂模式的动机 项目中的现状： 在软件系统中经常面临着“对象”的创建工作，由于需求的变化，这个对象可能随之也会发生变化，但它拥有着比较稳定的接口 为此，我们需要提供一种封装机制来隔离出这个易变对象的变化，从而保持系统中其他依赖该对象的对象不随着需求变化而变化 基于项目现状将代码进行如下设计： 1.尽量松耦合，一个对象的依赖对象的变化与本身无关 2.具体产品与客户端剥离，责任分割 发型工厂实例demo 实现接口 package com.example.demo.test3; /** * 发型接口 */ public

创建型模式的主要关注点是“怎样创建对象？”，它的主要特点是“将对象的创建与使用分离”。这样可以降低系统的耦合度，使用者不需要关注对象的创建细节，对象的创建由相关的工厂来完成。就像我们去商场购买商品时，不需要知道商品是怎么生产出来一样，因为它们由专门的厂商生产。 创建型模式分为以下几种。 单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。 原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。 工厂方法（FactoryMethod）模式：定义一个用于创建产品的接口，由子类决定生产什么产品。 抽象工厂（AbstractFactory）模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。 建造者（Builder）模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。 以上 5 种创建型模式，除了 工厂方法模式 属于类创建型模式，其他的全部属于对象创建型模式，我们将在之后的教程中详细地介绍它们的特点、结构与应用。 来源： https://www.cnblogs.com/sallyiszxm/p/10979656.html

工厂模式 将new操作单独封装 遇到new时，就要考虑该是否使用工厂模式 示例 当你去购买汉堡，直接点餐，取餐，不会自己亲手做 商店要“封装”做汉堡的工作，做好直接卖给买者 class Product { constructor(name) { this.name = name } init(){ alert('init') } fun1(){ alert('fun1') } fun2(){ alert('fun2') } } class Creator { creat(name) { return new Product() } } // 测试 let creat = new Creator() let p = creat.creat('p1') p.init() p,fun1() 工厂模式应用场景 jQuery-$('div') class jQuery { constructor(selector) { let slice = Array.prototype.slice let dom = slice.call(document.querySelectorAll(selector)) let len = dom ? dom.length : 0 for (let i = 0; i < len; i++) { this[i] = dom[i] } this.length =

一、 工厂模式介绍： 工厂模式实现了创建者和调用者的分离 工厂模式分类： 1.简单工厂模式 2.工厂方法模式：定义一个用于创建对象的接口，让子类决定实例化哪一个类，工厂方法使一个类的实例化延迟到其子类 ​ 3.抽象工厂模式：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。 面向对象设计的基本原则： OCP（开闭原则，Open-Closed Principle）： 一个软件的实体应当对扩展开放，对修改关闭。也就是说如果你要对一个已存在的系统做扩展的时候尽量要新增加类，而不是在原有的基础上修改。 DIP（依赖倒转原则，Dependence Inversion Principle） 针对接口编程，不要针对实现编程。 LoD（迪米特法则，Law Of Demeter） 只与你直接的朋友通信，而避免和陌生人通信。一个类尽量少的依赖其他类 二、工厂模式代码实现 未使用工厂模式的情况 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 //汽车接口 public interface Car { void run(); } //奥迪 public class Audi implements Car { @Override public void run() { System.out

<?php //工厂模式 interface Doing { function eat(); function sleep(); } class Cat implements Doing { function eat() { echo '猫正在吃东西！<br />'; } function sleep() { echo '猫正在睡觉！<br />'; } } class Dog implements Doing { function eat() { echo '狗正在吃东西！<br />'; } function sleep() { echo '狗正在睡觉！<br />'; } } class Factory { static function createDoing($type) { switch($type){ case 'cat': return new Cat(); break; case 'dog': return new Dog(); break; } } } $cat=Factory::createDoing('cat'); $dog=Factory::createDoing('dog'); 来源： https://www.cnblogs.com/shengChristine/p/10969138.html

补充： 继承： 父类和子类之间 共享数据和方法 的机制，一个父类可以有多个子类，父类描述了这些子类的公共属性和方法，一个子类可以继承它的父类中的属性和方法，这些属性和操作在子类中不必定义，子类中还可以定义自己的属性和方法。 多态： 在收到消息时，对象要给予响应，不同的对象收到同一消息可以产生完全不同的结果 参数多态： 一个类型是另一个类型的子类型 过载多态： 同一个名字在不同的上下文中所代表的含义不同 静态绑定： 在编译时进行的 动态绑定： 在运行时进行的，当一个对象发送消息请求服务时，要根据接收对象的具体情况将请求的操作与实现的方法进行连接 重置/覆盖： 在子类中重新定义父类中已经定义的方法，其基本思想是通过一种动态绑定机制的支持，使得子类在继承父类接口定义的前提下用适合自己要求的实现去置换父类中的相应实现 重载： 一个类可以具有多个同名而参数类型列表不同的方法，每个方法实现自己的特定行为 创建型设计模式： 抽象工厂（Abstract Factory）： ① 意图： 提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类 ②模式适应于： 一个系统要独立于它的产品的创建、组合和表示时。 一个系统要由多个产品系列中的一个配置时。 当要强调一系列相关的产品对象的设计以便进行联合使用时。 当提供一个产品类库，只想显示它们的接口而不是现实时。 例： 使用一个汽车生产来做例子

随着软件分层设计的流行及广泛的应用，对于DAO的设计模式大家已经不再陌生了，DAO层已经在软件系统的开发中成为必不可少的一层，将后台的数据层和前台的VO进行分离。前段时间也针对于DAO的设计介绍过一个基于Hibernate的泛型DAO的设计。 csdn blog：http://blog.csdn.net/yongtree/archive/2008/03/12/2172071.aspx javaeye blog：http://yongtree.iteye.com/blog/170449 通过DAO的设计的确可以让我们的软件系统已经将数据层和表现层进行了简单的分离，让我们系统各层次的功能更加的清晰。所以我们开始洋洋得意了，DAO的引入让系统的耦合性更加的松散，表现层再也不需要关心后台数据操作的变化了。于是我们开始高枕无忧了，我们肆无忌惮的在表现层通过调用DAO来实现我们的系统了。事实真的如此吗？那我们就举个例子来看看我们的系统是否真的具有解偶的能力了。 现在我们有个员工管理系统，在该系统中，Person.java表示员工这个对象，它对应着数据库中的person表。还有用于操作Person对象的DAO接口—PersonDAO.java，还有一个PersonDAO的实现类PersonDAOImpl.java。在PersonDAOImpl.java中我们实现了操作Person对象的所有的方法

1.工厂模式 具体包括了简单工厂、工厂方法、抽象工厂，它们是按照从简单到复杂的顺序排列的，属于设计模式中的创建型，其中简单工厂并不属于 GOF 的 23 中模式。但是它是理解其它的工厂模式的一个很好的基础，所以很多人在讲述设计模式的时候会提到简单工厂模式。创建型模式关注的是对象的创建，创建型模式将创建对象的过程进行了抽象，也可以理解为将创建对象的过程进行了封装，作为客户程序仅仅需要去使用对象，而不再关心创建对象过程中的逻辑 2 不使用任何模式 　　我们现在有这样的一个设计，影像家电（ VideoWiring ）包括了 DVD 、 VCD 。在基类 VideoWiring 中有 PlayVideo 方法，子类重载了这个方法。 　我们如何来调用 PlayVideo 进行播放呢。我们可以看到下面的代码可以实现。 　　下面是调用对象的方法进行播放的代码： public abstract class VideoWiring { public abstract string PlayVideo(); } public class VCD: VideoWiring { public override string PlayVideo() { return "正在播放播放VCD"; } } public class DVD: VideoWiring { public override string

一、定义 运用共享技术有效地支持大量细粒度的对象。又名“蝇量模式”。 说到享元模式，第一个想到的应该就是池技术了。String常量池、数据库连接池、缓冲池等等都是享元模式的应用，所以说享元模式是池技术的重要实现方式。比如我们每次创建字符串对象时，都需要创建一个新的字符串对象的话，内存开销会很大，所以如果第一次创建了字符串对象"adam"，下次再创建相同的字符串"adam"时，只是把它的引用指向"adam"，这样就实现了"adam"字符串再内存中的共享。 享元模式采用一个共享来避免大量拥有相同内容对象的开销。这种开销最常见、最直观的就是内存的消耗。享元对象能做到共享的关键是区分内部状态（Internal State）和外部状态（External State）。 内部状态是存储在享元对象内部的，不会随环境的改变而改变。内部状态是可以共享的。 外部状态是随环境的改变而改变的、不可以共享的。享元对象的外部状态必须由客户端保存，并在享元对象被创建之后，在需要使用的时候再传入到享元对象内部。外部状态不可以影响享元对象的内部状态，他们是相互独立的。 享元模式可以分成单纯享元模式和复合享元模式。 二、单纯享元模式 单纯享元模式包含的角色如下： 抽象享元角色（Flyweight）：给出一个抽象接口，以规定出所有具体享元角色需要实现的方法。 具体享元角色（ConcreteFlyweight)

目录 创建型模式： 简单工厂模式 工厂方法模式 抽象工厂模式 创建者模式 原型模式 单例模式 简单工厂模式 一、内容 不直接向客户端暴露对象创建的实现细节，而是通过一个工厂类来负责创建产品类的实例。 二、角色 工厂角色（Creator） 抽象产品角色（Product） 具体产品角色（Concrete Product） 三、优点 隐藏了对象创建的实现细节 客户端不需要修改代码 四、缺点 违反了单一职责原则，将创建逻辑集中到一个工厂类中 当添加新产品时，需要修改工厂类代码，违反了开放封闭原则 五、代码示例 from abc import abstractmethod,ABCMeta class Payment(metaclass=ABCMeta): @abstractmethod def pay(self,money): pass class Alipay(Payment): def pay(self, money): print('支付宝支付了%s元'%money) class Applepay(Payment): def pay(self, money): print('苹果支付了%s元' %money) class Yuebao(Payment): def pay(self,money): print('余额宝支付了%s元' %money) class