工厂模式

工厂模式代码其实很简单,道理也很简单,其实它的宗旨就是为了减少代码的的重复,以及后期业务逻辑变化,只需要改变很少的代码量 如果创建对象的过程都很复杂，需要一定的代码量，而且很多地方都要用到，那么就会有很多的重复代码。我们可以这些创建对象的代码放到工厂里统一管理。既减少了重复代码，也方便以后对的创建过程的修改维护。 统一管理，所以发生业务逻辑变化，不需要找到所有需要创建的地方去逐个修正，只需要在工厂里修改即可，降低维护成本。 package com.jttxtech.test; public interface Fruit { public void eat(); } class Apple implements Fruit { @Override public void eat() { System.out.println("苹果可以吃 !"); } } class Grape implements Fruit{ @Override public void eat() { System.out.println("葡萄可以吃 !"); } } /*创建一个水果工厂*/ class FruitFactory { public static Fruit createFactory(String name) { if("grape".equals(name)) { return new

  工厂模式主要分为简单工厂模式、工厂方法模式和抽象工厂模式，它主要作用是将对象实例化的部分抽取出来，降低代码的耦合度，其中简单工厂模式不属于23种设计模式。下面将对这三种模式进行介绍。 一、简单工厂模式 1.静态工厂模式   创建静态工厂方法，传入类型来返回相应实例。下面我们写一个简单工厂类来创建Vehicle实例。创建一个Vechile接口和实现它的三个具体类:Bike、Car、Trunk。静态工厂类代码如下所示： /** * 静态工厂类 */ public class VehicleFactory { public enum VehicleType{ Bike, Car, Truck; } public static Vehicle createVehicle(VehicleType type){ if(type.equals(VehicleType.Bike)){ return new Bike(); } if(type.equals(VehicleType.Car)){ return new Car(); } if(type.equals(VehicleType.Truck)){ return new Truck(); } return null; } }   工厂类逻辑很简单，只负责创建Vehicle类的实例，符合单一职责原则；用户只调用Vehicle接口

一、单例模式又称为职责模式，它用来在程序中创建一个单一功能的访问点，通俗地说就是实例化出来的对象是唯一的。 所有的单例模式至少拥有以下三种公共元素： 1. 它们必须拥有一个构造函数，并且必须被标记为private 2. 它们拥有一个保存类的实例的静态成员变量 3. 它们拥有一个访问这个实例的公共的静态方法 单例类不能再其它类中直接实例化，只能被其自身实例化。它不会创建实例副本，而是会向单例类内部存储的实例返回一个引用。 简单的单列模式: class RedisService{ /** * 类对象实例数组,共有静态变量 * @var null */ private static $_instance; /** * 私有化构造函数，防止类外实例化 * RedisConnect constructor. */ private function __construct() { } /** * 单例方法,用于访问实例的公共的静态方法 * @return \Redis * @static */ public static function getInstance() { if (!(self::$_instance instanceof \Redis)) { self::$_instance = new \Redis(); self::$_instance->connect('127.0.0

需求 针对店下商铺，有这样一个需求，对用户客户分为了普通客户、 vip 客户、超级 vip 用户、专属 vip 用户 4 个等级，每当用户购买商品时，针对不同的用户等级和消费金额采取不同的打折优惠策略。在平常的开发当中，必然会出现多层的 if-else 嵌套判断，先判断用户的等级再判断用户购买商品的消费金额。 弊端 以上的情况出现了多层的 if-else 嵌套，除此之外，以后如果需求再有变动，需要再增加一个用户等级，那么又会再次添加 if-else 的嵌套判断，那么如何解决上述的弊端呢，采用策略模式和工厂模式的搭配使用，可以很好地优化多层 if-else 的多层嵌套 实现 编写用户等级枚举类 package com.zbiti.ifelse.UserType; /** * 用户类型枚举类 */ public enum UserPayServiceEnum { VIP(1,"Vip"), SUPERVIP(2,"SuperVip"), PARTICULALYVIP(3,"ParticularlyVip"), NORMAL(4,"NormalPayService"); /** * 状态值 */ private int code; /** * 类型描述 */ private String value; private UserPayServiceEnum(int code, String

设计模式的六大原则 1、开闭原则（Open Close Principle） 对扩展开放，对修改关闭。 2、里氏代换原则（Liskov Substitution Principle） 任何基类可以出现的地方，子类一定可以出现。 3、依赖倒转原则（Dependence Inversion Principle） 对接口编程，依赖于抽象而不依赖于具体。 4、接口隔离原则（Interface Segregation Principle） 使用多个隔离的接口，比使用单个接口要好。降低依赖，降低耦合。 5、迪米特法则（最少知道原则）（Demeter Principle） 一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。 6、合成复用原则（Composite Reuse Principle） 尽量使用合成/聚合的方式，而不是使用继承。 Java的23中设计模式 分类 设计模式 创建型 5 工厂方法模式（FactoryMethod）、抽象工厂模式（AbstractFactory）、建造者模式（Builder）、原型模式（Prototype）、单例模式(Singleton) 结构型 7 适配器模式(Adapter)、桥接模式（Bridge）、组合模式（Composite）、装饰器模式（Decorator）、门面模式（Facade）、享元模式（Flyweight）、代理模式

引用自图解设计模式：https://design-patterns.readthedocs.io/zh_CN/latest/read_uml.html 车的类图结构为<<abstract>>，表示车是一个抽象类； 它有两个继承类：小汽车和自行车；它们之间的关系为实现关系，使用带空心箭头的虚线表示； 小汽车为与SUV之间也是继承关系，它们之间的关系为泛化关系，使用带空心箭头的实线表示； 小汽车与发动机之间是组合关系，使用带实心箭头的实线表示； 学生与班级之间是聚合关系，使用带空心箭头的实线表示； 学生与身份证之间为关联关系，使用一根实线表示；强关联的静态关系。 学生上学需要用到自行车，与自行车是一种依赖关系，使用带箭头的虚线表示；运行时产生的临时关系 简单工厂模式 Factory：工厂角色 工厂角色负责实现创建所有实例的内部逻辑 Product：抽象产品角色 抽象产品角色是所创建的所有对象的父类，负责描述所有实例所共有的公共接口 ConcreteProduct：具体产品角色 具体产品角色是创建目标，所有创建的对象都充当这个角色的某个具体类的实例。 　 优势：分离 对象的创建 和 对象本身业务处理，工厂方法是静态方法，只需要知道具体产品类所对应的参数 　　劣势：工厂类的职责相对过重，集中了所有产品创建逻辑，增加新的产品需要修改工厂类的判断逻辑 　　适用范围：工厂类负责创建的对象比较少

策略模式和工厂模式的搭配使用可以很好地消除代码 if-else 的多层嵌套 需求 针对店下商铺，有这样一个需求，对用户客户分为了普通客户、 vip 客户、超级 vip 用户、专属 vip 用户 4 个等级，每当用户购买商品时，针对不同的用户等级和消费金额采取不同的打折优惠策略。在平常的开发当中，必然会出现多层的 if-else 嵌套判断，先判断用户的等级再判断用户购买商品的消费金额。 弊端 以上的情况出现了多层的 if-else 嵌套，除此之外，以后如果需求再有变动，需要再增加一个用户等级，那么又会再次添加 if-else 的嵌套判断，那么如何解决上述的弊端呢，采用策略模式和工厂模式的搭配使用，可以很好地优化多层 if-else 的多层嵌套 实现 编写用户等级枚举类 java">package com.zbiti.ifelse.UserType; /** * 用户类型枚举类 */ public enum UserPayServiceEnum { VIP(1,"Vip"), SUPERVIP(2,"SuperVip"), PARTICULALYVIP(3,"ParticularlyVip"), NORMAL(4,"NormalPayService"); /** * 状态值 */ private int code; /** * 类型描述 */ private String value;

设计模式有哪些? 单例模式:单例模式对实例个数的控制并节约系统资源.在它的核心结构中只包含一个被称为单例类的特殊类,通过构造函数私有化和静态块以及提供对外访问的接口来实现. 应用场景：如果希望在系统中某个类的对象只能存在一个,单例模式是最好的解决方案。 工厂模式:工厂模式主要是为创建对象提供了接口 应用场景如下：在编码时不能预见需要创建哪种类的实例;系统不应依赖于产品类实例如何被创建、组合和表达的细节。 观察者模式:定义了对象间一对多的依赖关系，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新 应用场景如下：对一个对象状态的更新，需要其他对象同步更新，而且其他对象的数量动态可变；对象仅需要将自己的更新通知给其他对象而不需要知道其他对象的细节； (实现参考https://www.jianshu.com/p/12a009f8d016) 来源： https://www.cnblogs.com/yh2two/p/11782347.html

策略模式和工厂模式的搭配使用可以很好地消除代码 if-else 的多层嵌套 需求 针对店下商铺，有这样一个需求，对用户客户分为了普通客户、 vip 客户、超级 vip 用户、专属 vip 用户 4 个等级，每当用户购买商品时，针对不同的用户等级和消费金额采取不同的打折优惠策略。在平常的开发当中，必然会出现多层的 if-else 嵌套判断，先判断用户的等级再判断用户购买商品的消费金额。 弊端 以上的情况出现了多层的 if-else 嵌套，除此之外，以后如果需求再有变动，需要再增加一个用户等级，那么又会再次添加 if-else 的嵌套判断，那么如何解决上述的弊端呢，采用策略模式和工厂模式的搭配使用，可以很好地优化多层 if-else 的多层嵌套 实现 编写用户等级枚举类 package com.zbiti.ifelse.UserType; /** * 用户类型枚举类 */ public enum UserPayServiceEnum { VIP(1,"Vip"), SUPERVIP(2,"SuperVip"), PARTICULALYVIP(3,"ParticularlyVip"), NORMAL(4,"NormalPayService"); /** * 状态值 */ private int code; /** * 类型描述 */ private String value;

　　今天谈一下对工厂模式学习的总结。 　　看完视频和文章之后要自己表述工厂模式，总是感觉无从说起，不知道怎么去定义工厂模式，反复看了几遍之后终于理解一点。 　　自己理解工厂模式是通过这两种模式的特点来理解和定义的，首先工厂模式有简单工厂模式（不在23中设计模式中），工厂方法模式，抽象工厂模式，把三种模式对比来定义，根据不同模式的特点来记忆。 　　工厂模式是让对象的创建和使用分离，每次使用时不用自己创建，把创建对象的过程交给工厂来完成。 定义（仅供参考） 　　 工厂方法模式定义 ：定义创建一个产品的工厂接口，将这一个产品的具体创建方法延迟到子类工厂实现，当需要使用这个产品时通过工厂获取。 　　　　　　　　　　　　如果只有一类产品就说是简单工厂模式了. 　　 抽象工厂模式定义 ：定义创建一系列产品的工厂接口，将这一系列产品的具体创建过程延迟到子类工厂，使用时通过工厂就可以创建一系列的产品。 优缺点对比 　　 　　工厂方法模式： 　　　　 优点- 可以进行不同产品的扩展，如定义一个水果类工厂就可以创建不同的水果，现在要扩展一个蔬菜类产品就再定义一个蔬菜类工厂。 　　　　 缺点 -单要创建一系列产品类的时候，会出现工厂泛滥，一个产品类就要创建一个产品接口，一个产品工厂，增加系统复杂性。比如我还要创建动物类，工具类等， 　　　　　　工厂将越来越多。 　　抽象工厂模式： 　　　　 优点-