java工厂模式

Question

创建一个Cycle接口及其Unicycle,Bicycle的是实现。对每种类型的Cycle都创建相应的工厂，然后编写代码使用这写工厂。
interface Cycle{void run();}
interface CycleFactory{Cycle getCycle();}class Unicycle implements Cycle{
public void run(){
System.out.println("Unicycle!");
}
}class UnicycleFactory implements CycleFactory{
public Cycle getCycle(){return new Unicycle();}
}class Bicycle implements Cycle{
public  void run(){
System.out.println("Bicycle!");
}
}class BicycleFactory implements CycleFactory{
public Cycle getCycle(){ return new Bicycle();}
}
public class CycleTest {
public static void runBicycle(CycleFactory fact){
Cycle c = fact.getCycle();
c.run();
}
public static void main(String[] args) {
runBicycle(new UnicycleFactory());
runBicycle(new BicycleFactory()); }}这样写工厂模式有什么作用？不用工厂模式也可以很好的实现interface Cycle{void run();}
class Unicycle implements Cycle{
public void run(){
System.out.println("Unicycle!");
}
}class Bicycle implements Cycle{
public  void run(){
System.out.println("Bicycle!");
}
}
public class CycleTest {
public static void runBicycle(Cycle c){
c.run();
}
public static void main(String[] args) {
runBicycle(new Unicycle());
runBicycle(new Bicycle()); }}
java 工厂模式

Answer 1

不同意你的观点，他这种写法是标准的工厂方法模式，没什么问题。解释下个人对工厂方法模式的理解：
有人会觉得这和直接调用具体产品类的构造方法似乎没有什么区别，因为使用者必然会“知道”一个具体类的构造方法，不是具体产品的构造方法，就是具体工厂的构造方法。问题的关键在于，具体产品类的构造方法和具体工厂类的构造方法，哪一个更“稳定”？具体工厂本质上只是一个封装层，内部不具有任何逻辑代码；而具体产品则不同，它和业务逻辑往往紧密关联，产品的功能实现来源于具体业务。很明显，相比较之下，具体工厂类和业务的相关性几乎为0，也就是说它们“被改动的风险”几乎为0，在这种情况下，使用者依赖具体工厂类，要远好过直接依赖具体产品类。工厂模式有很多变化，各有优缺点，适用不同的场景，具体的看下我这篇文章。
http://www.cnblogs.com/liqingyuan/archive/2013/05/20/model_02.html

Answer 2

不同意你的观点，他这种写法是标准的工厂方法模式，没什么问题。解释下个人对工厂方法模式的理解：
有人会觉得这和直接调用具体产品类的构造方法似乎没有什么区别，因为使用者必然会“知道”一个具体类的构造方法，不是具体产品的构造方法，就是具体工厂的构造方法。问题的关键在于，具体产品类的构造方法和具体工厂类的构造方法，哪一个更“稳定”？具体工厂本质上只是一个封装层，内部不具有任何逻辑代码；而具体产品则不同，它和业务逻辑往往紧密关联，产品的功能实现来源于具体业务。很明显，相比较之下，具体工厂类和业务的相关性几乎为0，也就是说它们“被改动的风险”几乎为0，在这种情况下，使用者依赖具体工厂类，要远好过直接依赖具体产品类。工厂模式有很多变化，各有优缺点，适用不同的场景，具体的看下我这篇文章。
http://www.cnblogs.com/liqingyuan/archive/2013/05/20/model_02.html我说的是用法不对，没说写法不对，你分得清用法和写法的却别不？

Answer 3

不同意你的观点，他这种写法是标准的工厂方法模式，没什么问题。解释下个人对工厂方法模式的理解：
有人会觉得这和直接调用具体产品类的构造方法似乎没有什么区别，因为使用者必然会“知道”一个具体类的构造方法，不是具体产品的构造方法，就是具体工厂的构造方法。问题的关键在于，具体产品类的构造方法和具体工厂类的构造方法，哪一个更“稳定”？具体工厂本质上只是一个封装层，内部不具有任何逻辑代码；而具体产品则不同，它和业务逻辑往往紧密关联，产品的功能实现来源于具体业务。很明显，相比较之下，具体工厂类和业务的相关性几乎为0，也就是说它们“被改动的风险”几乎为0，在这种情况下，使用者依赖具体工厂类，要远好过直接依赖具体产品类。工厂模式有很多变化，各有优缺点，适用不同的场景，具体的看下我这篇文章。
http://www.cnblogs.com/liqingyuan/archive/2013/05/20/model_02.html我说的是用法不对，没说写法不对，你分得清用法和写法的却别不？不好意思，打错字了，是区别，不是却别

Answer 4

不同意你的观点，他这种写法是标准的工厂方法模式，没什么问题。解释下个人对工厂方法模式的理解：
有人会觉得这和直接调用具体产品类的构造方法似乎没有什么区别，因为使用者必然会“知道”一个具体类的构造方法，不是具体产品的构造方法，就是具体工厂的构造方法。问题的关键在于，具体产品类的构造方法和具体工厂类的构造方法，哪一个更“稳定”？具体工厂本质上只是一个封装层，内部不具有任何逻辑代码；而具体产品则不同，它和业务逻辑往往紧密关联，产品的功能实现来源于具体业务。很明显，相比较之下，具体工厂类和业务的相关性几乎为0，也就是说它们“被改动的风险”几乎为0，在这种情况下，使用者依赖具体工厂类，要远好过直接依赖具体产品类。工厂模式有很多变化，各有优缺点，适用不同的场景，具体的看下我这篇文章。
http://www.cnblogs.com/liqingyuan/archive/2013/05/20/model_02.html我说的是用法不对，没说写法不对，你分得清用法和写法的却别不？用法也没问题，他一样是把子类工厂实例丢给接口引用。

Answer 5

不同意你的观点，他这种写法是标准的工厂方法模式，没什么问题。解释下个人对工厂方法模式的理解：
有人会觉得这和直接调用具体产品类的构造方法似乎没有什么区别，因为使用者必然会“知道”一个具体类的构造方法，不是具体产品的构造方法，就是具体工厂的构造方法。问题的关键在于，具体产品类的构造方法和具体工厂类的构造方法，哪一个更“稳定”？具体工厂本质上只是一个封装层，内部不具有任何逻辑代码；而具体产品则不同，它和业务逻辑往往紧密关联，产品的功能实现来源于具体业务。很明显，相比较之下，具体工厂类和业务的相关性几乎为0，也就是说它们“被改动的风险”几乎为0，在这种情况下，使用者依赖具体工厂类，要远好过直接依赖具体产品类。工厂模式有很多变化，各有优缺点，适用不同的场景，具体的看下我这篇文章。
http://www.cnblogs.com/liqingyuan/archive/2013/05/20/model_02.html我说的是用法不对，没说写法不对，你分得清用法和写法的却别不？用法也没问题，他一样是把子类工厂实例丢给接口引用。你觉得所谓的“用法” 就是指代码调用方法吗？ 我指的不是这个~ 

Answer 6

不同意你的观点，他这种写法是标准的工厂方法模式，没什么问题。解释下个人对工厂方法模式的理解：
有人会觉得这和直接调用具体产品类的构造方法似乎没有什么区别，因为使用者必然会“知道”一个具体类的构造方法，不是具体产品的构造方法，就是具体工厂的构造方法。问题的关键在于，具体产品类的构造方法和具体工厂类的构造方法，哪一个更“稳定”？具体工厂本质上只是一个封装层，内部不具有任何逻辑代码；而具体产品则不同，它和业务逻辑往往紧密关联，产品的功能实现来源于具体业务。很明显，相比较之下，具体工厂类和业务的相关性几乎为0，也就是说它们“被改动的风险”几乎为0，在这种情况下，使用者依赖具体工厂类，要远好过直接依赖具体产品类。工厂模式有很多变化，各有优缺点，适用不同的场景，具体的看下我这篇文章。
http://www.cnblogs.com/liqingyuan/archive/2013/05/20/model_02.html我说的是用法不对，没说写法不对，你分得清用法和写法的却别不？用法也没问题，他一样是把子类工厂实例丢给接口引用。好搞笑...一个设计模式用得好,就是要让别人看不出不和谐的地方,既然楼主第一种方式都感觉到不和谐,就证明有点大题小做,但是下面的实现定义接口就看着舒服简单多了,证明这个简单的问题应用第二种简单的接口定义实现

Answer 7

楼上的两位别吵了，只讨论技术，不要人身攻击，也不提倡诡辩，没有意义。工厂模式在单独的代码里讨论没有意义，要放在一个大的项目框架下才有意义。这里就不得不提一下Spring，其最基本的功能就是一个大工厂，负责装配各种组件。在你的例子里，工厂并没有提供装配组件的功能，这是一个幼稚的工厂，在这个例子里，直接new和工厂没有区别。但是，一旦加上了其他组件，就不同了。我觉得可以写一篇博来讲这个，先简单提一下：
interface ICycle {
  void run();
  void setWheel(IWheel wheel);
}Unicycle implements ICycle {
  private IWheel iWheel;
  @Override
  public void run() {System.out.println("Unicycle of wheel: " + iWheel;)}
  public void setWheel(IWheel wheel) {iWheel = wheel;}
}Bicycle implements ICycle {
  private IWheel iWheel;
  @Override
  public void run() {System.out.println("Bicycle of wheel: " + iWheel;)}
  public void setWheel(IWheel wheel) {iWheel = wheel;}
}GoodWheel implements IWheel {
  @Override
  public String toString() {return "good wheel";}
}BadWheel implements IWheel {
  @Override
  public String toString() {return "bad wheel";}
}interface ICycleFactory{
  ICycle getCycle();
}class GoodWheelBicycleFactory implements ICycleFactory {
  @Override
  public ICycle getCycle() {
    iCycle cycle = new Bicycle();
    cycle.setWheel(new GoodWheel());
    return cycle;
  }
}public static void main (final String[] args) {
  runCycle (new GoodWheelBicycleFactory());
}对比下面的代码：
interface ICycle {
  void run();
  void setWheel(IWheel wheel);
}Unicycle implements ICycle {
  private IWheel iWheel;
  @Override
  public void run() {System.out.println("Unicycle of wheel: " + iWheel;)}
  public void setWheel(IWheel wheel) {iWheel = wheel;}
}Bicycle implements ICycle {
  private IWheel iWheel;
  @Override
  public void run() {System.out.println("Bicycle of wheel: " + iWheel;)}
  public void setWheel(IWheel wheel) {iWheel = wheel;}
}GoodWheel implements IWheel {
  @Override
  public String toString() {return "good wheel";}
}BadWheel implements IWheel {
  @Override
  public String toString() {return "bad wheel";}
}public static void main (final String[] args) {
  Cycle cycle = new Bicycle();
  cycle.setWheel(new Wheel());
  runCycle (cycle);
}这里只有一个cycle，假设不同的Cycle有不同的Wheel，这样排列组合一下光是这里已经有4个组合了。在一个复杂的程序里，组件的数量远远不止这一些，而且你使用API的时候，如果组件的装配由你自己来实现，这将是一件多么混乱的事情。所以就有了工厂模式，把某一种组件的装配包装成一个有意义的类，便于使用。

Answer 8

组件的装配
这个是Builder模式，不是工厂模式。
他们都是创建的模式，但是有一些区别。

Answer 9

Builder模式主要用来替代构造函数的重载。这么说：一个汽车车间，给一辆车装上德国引擎或者国产引擎，生产出两种不同的车，比较像工厂；同样的车间，一个给车上装了音响，一个没装，这就比较像Builder的用法。（见Effective Java 第二版Item2）