工厂类

意图： •专门定义一个类来负责创建其他类的实例,被创建的实例通常都具有共同的父类. •(Simple Factory)模式又称为静态工厂方法(Static Factory Method)模式,属于类的创建型模式,通常他根据自变量的不同返回不同类的实例. •简单工厂模式实质是由一个工厂类根据传入的参量,动态的决定应该创建出哪一个产品类的实例. •简单工厂模式实际上不属于23个GOF模式,但他可以作为工厂方法模式(Factory Method)的一个引导. UML图： 该模式中包含的角色及其职责： 　　 工厂（SimpleFactory）角色 　　简单工厂模式的核心，它负责实现创建所有实例的内部逻辑。工厂类可以被外界直接调用，创建所需的产品对象。 　　 抽象产品（Product）角色 　　简单工厂模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口。 　　 具体产品（Concrete Product）角色 　　是简单工厂模式的创建目标，所有创建的对象都是充当这个角色的某个具体类的实例。 优缺点分析： 优点 •工厂类是整个模式的关键.包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象.通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了．而不必管这些对象究竟如何创建及如何组织的．明确了各自的职责和权利

单例模式的目的：保证一个类仅有一个实例，并提供一个访问实例的全局访问点。 要点：1、单例类拥有一个私有构造函数，确保用户无法通过new 关键字去直接实例化它。 2、单例模式包含一个静态私有成员变量与静态公用工厂方法。 设计代码： public class Singleton{ private static Singleton instance=null; private Singleton(){ } public static Singleton getInstance(){ if(instance==null){ instance = new Singleton(); } return instance; } } 简单工厂模式 模式分析： 1.将对象的创建和对象本身的业务处理分离，可以降低系统的耦合度，使得两者修改起来都相对容易。 2.在调用工厂类的工厂方法是，由于工厂方法是静态方法，使用起来很方便，可通过类名直接调用，而且只需要传入一个简单的参数即可，在实际开发中，还可以在调用时将所传入的参数保存在XML等格式的配置文件中，修改参数是无须修改任何的java源代码。 3.简单工厂模式最大的问题是工厂类的职责相对过重，增加新的产品需要修改工厂类的判断逻辑，这一点与开闭原则是相对违背的。 4.简单工厂模式的要点在于：当你需要什么，只需要传入一个正确的参数，就可以获取你所需要的对象

using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace _016 { //抽象类（菜） public abstract class Food { //抽象方法，输出点了的菜 //抽象方法接下来会被重写，直接调用抽象方法就可以 public abstract void Print();//抽象方法没有方法体 } //打印土豆丝 类 //重写抽象方法 public class tds : Food { public override void Print() { Console.WriteLine("来份土豆丝"); } } //打印西红柿 类 //抽血抽象方法 public class xhs : Food { public override void Print() { Console.WriteLine("来份西红柿"); } } //工厂类 厨师 public class cs { public static Food CreateFood(string t) { Food food = null; if (t.Equals("土豆丝")) { food = new tds(); } else if (t.Equals("西红柿")) {

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

关于JNDI： 命名系统是一组关联的上下文，而上下文是包含零个或多个绑定的对象，每个绑定都有一个原子名(实际上就是给绑定的对象起个名字，方便查找该绑定的对象)， 使用JNDI的好处就是配置统一的管理接口，下层可以使用RMI、LDAP或者CORBA来访问目标服务 要获取初始上下文，需要使用初始上下文工厂 比如JNDI+RMI Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.rmi.registry.RegistryContextFactory"); env.put(Context.PROVIDER_URL, "rmi://localhost:9999"); Context ctx = new InitialContext(env); //将名称refObj与一个对象绑定，这里底层也是调用的rmi的registry去绑定 ctx.bind("refObj", new RefObject()); //通过名称查找对象 ctx.lookup("refObj"); 比如JNDI+LDAP Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi

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

　　前言　　 　　在介绍工厂方法模式之前，我们需要知道这个设计模式是什么，解决了什么样的问题？在上一篇博客 设计模式（Java语言）- 简单工厂模式 介绍了简单工厂模式，然后总结了简单工厂模式的缺点： 　　　　1、当新增类型时，我们不得不修改原来的工厂，这样就违背了设计模式6大原则中的 开闭原则。 　　　　2、简单工厂模式使用了静态方法来创建对象，因此无法被实现或继承，从而导致改工厂类缺少灵活性，不易拓展。 　　　　3、所有的类的创建都需要这个工厂类，因此系统已工厂类是强依赖的关系，一旦工厂类出现错误，将对整个系统产生比较大的影响。 　　工厂方法模式就是解决上简单工厂模式的缺点。工厂方法模式UML类图： 　　创建工厂方法模式步骤 　　1、创建抽象产品类，定义接口。 　　2、创建抽象工厂，定义具体工厂的接口。 　　3、创建具体的产品类 　　4、创建具体的工厂类 　　5、客户端调用工厂类创建对象 　　 　　应用案例 　　本模式我们加ing继续使用创建手机作为例子来讲解。我们根据上面的步骤来完成创建手机的流程： 　　第一步定义抽象工厂方法： /** * @className: IphoneFactory * @description: iphone手机工厂类 * @author: rainple * @create: 2020-01-21 20:52 **/ public class

控制反转 IoC 简介 在实际的应用开发中，我们需要尽量避免和降低对象间的依赖关系，即降低耦合度。通常的业务对象之间都是互相依赖的，业务对象与业务对象、业务对象与持久层、业务对象与各种资源之间都存在这样或那样的依赖关系。但是如何才能做到降低类之间的依赖关系呢？这就是本文核心IoC需要解决的问题，下面从两大点具体介绍IoC： （1） IoC 与 DI 的基本概念 IoC（Inversion Of Control）即控制反转，其具体就是由容器来控制业务对象之间的依赖关系，而不是像传统方式中由代码来直接控制。控制反转的本质，是控制权由应用代码转到了外部容器，控制权的转移即是所谓的反转。控制权的转移带来的好处就是降低了业务对象之间的依赖程度，即实现了解耦。 IoC的实现策略有两种： 1) 依赖查找： 容器中的受控对象通过容器的API来查找自己所依赖的资源和协作对象。这种方式虽然降低了对象间的依赖，但是同时也使用到了容器的API，造成了我们无法在容器外使用和测试对象； 2) 依赖注入（又称 DI ： Dependency Injection ）： 对象只提供普通的方法让容器去决定依赖关系，容器全权负责组建的装配，它会把符合依赖关系的对象通过属性或者是构造函数传递给需要的对象。通过属性注射依赖关系的做法称为设值方法注入，将构造子参数传入的做法称为构造子注入。 依赖注入的好处如下：

线程池思想概述 线程的复用，执行王一个任务，并不被销毁，而是可以继续执行其他任务。 java.util.concurrent Executors类 （生产线程池的工厂类） 线程池:JDK1.5之后提供的 java.util.concurrent.Executors:线程池的工厂类，用来生成线程池 Executors类种的静态方法： static ExecutorService newFixedThreadPool(int nThreads)创建一个可重用固定线程数的线程池 参数： int nThreads:创建线程池中包含线程数量 返回值: ExecutorService接口，返回的时ExecutorService接口的实现类对象，我们可以使用ExecutorService接口接受（面向接口编程) java.util.concurrent.ExecutorService:线程池接口 用来从线程池中获取线程，调用start方法，执行线程任务 submit(Runnable task)提交一个Runnable任务用于执行 关闭/销售线程池的方法 void shutdown() 线程池的使用步骤： 1.使用线程池的工厂类Executors里面提供的静态方法newFixedThreadPool生产一个指定线程数量的线程池 2.创建一个类，实现Runnable借口，重写run方法

一、 普通工厂模式 就是建立一个工厂类，对实现了同一接口的一些类进行实例的创建。首先看下关系图： 举例如下：（我们举一个发送邮件和短信的例子） 首先，创建二者的共同接口： package test.factory; public interface Sender { public void Send(); } 其次，创建实现类： 邮件实现类 package test.factory; import lombok.extern.slf4j.Slf4j; @Slf4j public class MailSender implements Sender{ @Override public void Send() { log.info("this is mail"); } } 短信实现类 package test.factory; import lombok.extern.slf4j.Slf4j; @Slf4j public class SmsSender implements Sender { @Override public void Send() { log.info("this is sms"); } } 最后，建工厂类： package test.factory; import lombok.extern.slf4j.Slf4j; @Slf4j public class