wordpress form 高度,网站关键词优化推广哪家好,seo的搜索排名影响因素有哪些,青蛙网站建设在面向对象编程中#xff0c; 最通常的方法是一个new操作符产生一个对象实例#xff0c;new操作符就是用来构造对象实例的。但是在一些情况下#xff0c;new操作符直接生成对象会带来一些问题。举例来说#xff0c;许多类型对象的创造需要一系列的步骤#xff1a;你可能需… 在面向对象编程中 最通常的方法是一个new操作符产生一个对象实例new操作符就是用来构造对象实例的。但是在一些情况下new操作符直接生成对象会带来一些问题。举例来说许多类型对象的创造需要一系列的步骤你可能需要计算或取得对象的初始设置选择生成哪个子对象实例或在生成你需要的对象之前必须先生成一些辅助功能的对象。在这些情况,新对象的建立就是一个 过程不仅是一个操作像一部大机器中的一个齿轮传动。 模式的问题你如何能轻松方便地构造对象实例而不必关心构造对象实例的细节和复杂过程呢 解决方案建立一个工厂来创建对象 实现 一、引言 1还没有工厂时代假如还没有工业革命如果一个客户要一款宝马车一般的做法是客户去创建一款宝马车然后拿来用。 2简单工厂模式后来出现工业革命。用户不用去创建宝马车。因为客户有一个工厂来帮他创建宝马.想要什么车这个工厂就可以建。比如想要320i系列车。工厂就创建这个系列的车。即工厂可以创建产品。 3工厂方法模式时代为了满足客户宝马车系列越来越多如320i523i30li等系列一个工厂无法创建所有的宝马系列。于是由单独分出来多个具体的工厂。每个具体工厂创建一种系列。即具体工厂类只能创建一个具体产品。但是宝马工厂还是个抽象。你需要指定某个具体的工厂才能生产车出来。 4抽象工厂模式时代随着客户的要求越来越高宝马车必须配置空调。于是这个工厂开始生产宝马车和需要的空调。 最终是客户只要对宝马的销售员说我要523i空调车销售员就直接给他523i空调车了。而不用自己去创建523i空调车宝马车。 这就是工厂模式。 二、分类 工厂模式主要是为创建对象提供过渡接口以便将创建对象的具体过程屏蔽隔离起来达到提高灵活性的目的。 工厂模式可以分为三类 1简单工厂模式Simple Factory 2工厂方法模式Factory Method 3抽象工厂模式Abstract Factory 这三种模式从上到下逐步抽象并且更具一般性。 GOF在《设计模式》一书中将工厂模式分为两类工厂方法模式Factory Method与抽象工厂模式Abstract Factory。 将简单工厂模式Simple Factory看为工厂方法模式的一种特例两者归为一类。 三、区别 工厂方法模式 一个抽象产品类可以派生出多个具体产品类。 一个抽象工厂类可以派生出多个具体工厂类。 每个具体工厂类只能创建一个具体产品类的实例。 抽象工厂模式 多个抽象产品类每个抽象产品类可以派生出多个具体产品类。 一个抽象工厂类可以派生出多个具体工厂类。 每个具体工厂类可以创建多个具体产品类的实例。区别 工厂方法模式只有一个抽象产品类而抽象工厂模式有多个。 工厂方法模式的具体工厂类只能创建一个具体产品类的实例而抽象工厂模式可以创建多个。 两者皆可。 四、简单工厂模式 建立一个工厂一个函数或一个类方法来制造新的对象。 分布说明引子从无到有。客户自己创建宝马车然后拿来用。 public class BMW320 { public BMW320(){ System.out.println(制造--BMW320); }
} public class BMW523 { public BMW523(){ System.out.println(制造--BMW523); }
} public class Customer { public static void main(String[] args) { BMW320 bmw320 new BMW320(); BMW523 bmw523 new BMW523(); }
} 客户需要知道怎么去创建一款车客户和车就紧密耦合在一起了。为了降低耦合就出现了工厂类把创建宝马的操作细节都放到了工厂里面去客户直接使用工厂的创建工厂方法传入想要的宝马车型号就行了而不必去知道创建的细节。这就是工业革命了简单工厂模式 即我们建立一个工厂类方法来制造新的对象。如图 产品类 abstract class BMW { public BMW(){ }
} public class BMW320 extends BMW { public BMW320() { System.out.println(制造--BMW320); }
}
public class BMW523 extends BMW{ public BMW523(){ System.out.println(制造--BMW523); }
} 工厂类 public class Factory { public BMW createBMW(int type) { switch (type) { case 320: return new BMW320(); case 523: return new BMW523(); default: break; } return null; }
} 客户类 public class Customer { public static void main(String[] args) { Factory factory new Factory(); BMW bmw320 factory.createBMW(320); BMW bmw523 factory.createBMW(523); }
} 简单工厂模式又称静态工厂方法模式。重命名上就可以看出这个模式一定很简单。它存在的目的很简单定义一个用于创建对象的接口。 先来看看它的组成 1) 工厂类角色这是本模式的核心含有一定的商业逻辑和判断逻辑用来创建产品 2) 抽象产品角色它一般是具体产品继承的父类或者实现的接口。 3) 具体产品角色工厂类所创建的对象就是此角色的实例。在java中由一个具体类实现。 下面我们从开闭原则对扩展开放对修改封闭上来分析下简单工厂模式。当客户不再满足现有的车型号的时候想要一种速度快的新型车只要这种车符合抽象产品制定的合同那么只要通知工厂类知道就可以被客户使用了。所以对产品部分来说它是符合开闭原则的但是工厂部分好像不太理想因为每增加一种新型车都要在工厂类中增加相应的创建业务逻辑createBMW(int type)方法需要新增case这显然是违背开闭原则的。可想而知对于新产品的加入工厂类是很被动的。对于这样的工厂类我们称它为全能类或者上帝类。 我们举的例子是最简单的情况而在实际应用中很可能产品是一个多层次的树状结构。由于简单工厂模式中只有一个工厂类来对应这些产品所以这可能会把我们的上帝累坏了也累坏了我们这些程序员。 于是工厂方法模式作为救世主出现了。工厂类定义成了接口而每新增的车种类型,就增加该车种类型对应工厂类的实现这样工厂的设计就可以扩展了而不必去修改原来的代码。 五、工厂方法模式 工厂方法模式去掉了简单工厂模式中工厂方法的静态属性使得它可以被子类继承。这样在简单工厂模式里集中在工厂方法上的压力可以由工厂方法模式里不同的工厂子类来分担。 工厂方法模式组成 1)抽象工厂角色这是工厂方法模式的核心它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。 2)具体工厂角色它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。 3)抽象产品角色它是具体产品继承的父类或者是实现的接口。在java中一般有抽象类或者接口来实现。 4)具体产品角色具体工厂角色所创建的对象就是此角色的实例。在java中由具体的类来实现。 工厂方法模式使用继承自抽象工厂角色的多个子类来代替简单工厂模式中的“上帝类”。正如上面所说这样便分担了对象承受的压力而且这样使得结构变得灵活 起来——当有新的产品产生时只要按照抽象产品角色、抽象工厂角色提供的合同来生成那么就可以被客户使用而不必去修改任何已有 的代码。可以看出工厂角色的结构也是符合开闭原则的 代码如下 产品类 abstract class BMW { public BMW(){ }
}
public class BMW320 extends BMW { public BMW320() { System.out.println(制造--BMW320); }
}
public class BMW523 extends BMW{ public BMW523(){ System.out.println(制造--BMW523); }
} 创建工厂类 interface FactoryBMW { BMW createBMW();
} public class FactoryBMW320 implements FactoryBMW{ Override public BMW320 createBMW() { return new BMW320(); } }
public class FactoryBMW523 implements FactoryBMW { Override public BMW523 createBMW() { return new BMW523(); }
} 客户类 public class Customer { public static void main(String[] args) { FactoryBMW320 factoryBMW320 new FactoryBMW320(); BMW320 bmw320 factoryBMW320.createBMW(); FactoryBMW523 factoryBMW523 new FactoryBMW523(); BMW523 bmw523 factoryBMW523.createBMW(); }
} 工厂方法模式仿佛已经很完美的对对象的创建进行了包装使得客户程序中仅仅处理抽象产品角色提供的接口但使得对象的数量成倍增长。当产品种类非常多时会出现大量的与之对应的工厂对象这不是我们所希望的。 例子背景 随着客户的要求越来越高宝马车需要不同配置的空调和发动机等配件。于是这个工厂开始生产空调和发动机用来组装汽车。这时候工厂有两个系列的产品:空调和发动机。宝马320系列配置A型号空调和A型号发动机宝马230系列配置B型号空调和B型号发动机。 概念 抽象工厂模式是工厂方法模式的升级版本他用来创建一组相关或者相互依赖的对象。比如宝马320系列使用空调型号A和发动机型号A而宝马230系列使用空调型号B和发动机型号B那么使用抽象工厂模式在为320系列生产相关配件时就无需制定配件的型号它会自动根据车型生产对应的配件型号A。 针对百度百科上对于抽象工厂模式的简介结合本例如下 当每个抽象产品都有多于一个的具体子类的时候空调有型号A和B两种发动机也有型号A和B两种工厂角色怎么知道实例化哪一个子类呢比如每个抽象产品角色都有两个具体产品产品空调有两个具体产品空调A和空调B。抽象工厂模式提供两个具体工厂角色宝马320系列工厂和宝马230系列工厂分别对应于这两个具体产品角色每一个具体工厂角色只负责某一个产品角色的实例化。每一个具体工厂类只负责创建抽象产品的某一个具体子类的实例。 抽象工厂模式代码 产品类 //发动机以及型号
public interface Engine { }
public class EngineA extends Engine{ public EngineA(){ System.out.println(制造--EngineA); }
}
public class EngineBextends Engine{ public EngineB(){ System.out.println(制造--EngineB); }
} //空调以及型号
public interface Aircondition { }
public class AirconditionA extends Aircondition{ public AirconditionA(){ System.out.println(制造--AirconditionA); }
}
public class AirconditionB extends Aircondition{ public AirconditionB(){ System.out.println(制造--AirconditionB); }
} 创建工厂类 //创建工厂的接口
public interface AbstractFactory { //制造发动机 public Engine createEngine(); //制造空调 public Aircondition createAircondition();
} //为宝马320系列生产配件
public class FactoryBMW320 implements AbstractFactory{ Override public Engine createEngine() { return new EngineA(); } Override public Aircondition createAircondition() { return new AirconditionA(); }
}
//宝马523系列
public class FactoryBMW523 implements AbstractFactory { Override public Engine createEngine() { return new EngineB(); } Override public Aircondition createAircondition() { return new AirconditionB(); } } 客户 public class Customer { public static void main(String[] args){ //生产宝马320系列配件 FactoryBMW320 factoryBMW320 new FactoryBMW320(); factoryBMW320.createEngine(); factoryBMW320.createAircondition(); //生产宝马523系列配件 FactoryBMW523 factoryBMW523 new FactoryBMW523(); factoryBMW320.createEngine(); factoryBMW320.createAircondition(); }
} 关于抽象工厂模式与工厂方法模式的区别这里就不说了感觉多看几遍例子就能理解还有很多提到的产品族、等级结构等概念说了反而更难理解。 抽象工厂模式的起源 下面引用一段抽象工厂模式的起源 抽象工厂模式的起源或者最早的应用是用于创建分属于不同操作系统的视窗构建。比如命令按键Button与文字框Text)都是视窗构建在UNIX操作系统的视窗环境和Windows操作系统的视窗环境中这两个构建有不同的本地实现它们的细节有所不同。 在每一个操作系统中都有一个视窗构建组成的构建家族。在这里就是Button和Text组成的产品族。而每一个视窗构件都构成自己的等级结构由一个抽象角色给出抽象的功能描述而由具体子类给出不同操作系统下的具体实现。 可以发现在上面的产品类图中有两个产品的等级结构分别是Button等级结构和Text等级结构。同时有两个产品族也就是UNIX产品族和Windows产品族。UNIX产品族由UNIX Button和UNIX Text产品构成而Windows产品族由Windows Button和Windows Text产品构成。 系统对产品对象的创建需求由一个工程的等级结构满足其中有两个具体工程角色即UnixFactory和WindowsFactory。UnixFactory对象负责创建Unix产品族中的产品而WindowsFactory对象负责创建Windows产品族中的产品。这就是抽象工厂模式的应用抽象工厂模式的解决方案如下图 显然一个系统只能够在某一个操作系统的视窗环境下运行而不能同时在不同的操作系统上运行。所以系统实际上只能消费属于同一个产品族的产品。 在现代的应用中抽象工厂模式的使用范围已经大大扩大了不再要求系统只能消费某一个产品族了。 总结 无论是简单工厂模式工厂方法模式还是抽象工厂模式他们都属于工厂模式在形式和特点上也是极为相似的他们的最终目的都是为了解耦。在使用时我们不必去在意这个模式到底工厂方法模式还是抽象工厂模式因为他们之间的演变常常是令人琢磨不透的。经常你会发现明明使用的工厂方法模式当新需求来临稍加修改加入了一个新方法后由于类中的产品构成了不同等级结构中的产品族它就变成抽象工厂模式了而对于抽象工厂模式当减少一个方法使的提供的产品不再构成产品族之后它就演变成了工厂方法模式。 所以在使用工厂模式时只需要关心降低耦合度的目的是否达到了。 本文转自http://blog.csdn.net/jason0539/article/details/23020989 转载于:https://www.cnblogs.com/dreammyle/p/5405092.html
