[英]Are all of these method signatures valid for simple factory pattern?
我正在学习简单的工厂模式,我想知道我工厂中的所有方法对于这种模式是否有效:
public class Bmw implements Car {
private String color;
private boolean hasXDrive;
public Bmw() {
}
public Bmw(String color) {
this.color = color;
}
public Bmw(String color, boolean hasXDrive) {
this.color = color;
this.hasXDrive = hasXDrive;
}
public String getColor() {
return color;
}
public void setColor(String color) {
this.color = color;
}
public boolean isHasXDrive() {
return hasXDrive;
}
public void setHasXDrive(boolean hasXDrive) {
this.hasXDrive = hasXDrive;
}
}
public class Audi implements Car {
private String color;
private int turnAssistLevel;
public Audi() {
}
public Audi(String color) {
this.color = color;
}
public Audi(String color, int turnAssistLevel) {
this.color = color;
this.turnAssistLevel = turnAssistLevel;
}
public String getColor() {
return color;
}
public void setColor(String color) {
this.color = color;
}
public int getTurnAssistLevel() {
return turnAssistLevel;
}
public void setTurnAssistLevel(int turnAssistLevel) {
this.turnAssistLevel = turnAssistLevel;
}
}
public class SimpleCarFactory {
// 1. make empty cars
public Car makeCar(CarType carType) {
switch (carType) {
case AUDI:
return new Audi();
case BMW:
return new Bmw();
default:
throw new RuntimeException("No such car type!");
}
}
// 2. make cars with colors
public Car makeCarWithColor(CarType carType, String color) {
switch (carType) {
case AUDI:
return new Audi(color);
case BMW:
return new Bmw(color);
default:
throw new RuntimeException("No such car type!");
}
}
// 3. BMW has an option that differentiate it from any other car. We cannot use a general car factory anymore
public Car makeBmw(String color, boolean hasXDrive) {
return new Bmw(color, hasXDrive);
}
// 4. Audi has a turnAssistLevel option
public Car makeAudi(String color, int turnAssistLevel) {
return new Audi(color, turnAssistLevel);
}
// 5. The same as #1, only it is static now make empty cars
public static Car staticMakeCar(CarType carType) {
switch (carType) {
case AUDI:
return new Audi();
case BMW:
return new Bmw();
default:
throw new RuntimeException("No such car type!");
}
}
}
我在代码注释中添加了方法的变体。 我之所以问这些问题,是因为通常情况下,您会基于一些区分符(CarType)创建一个子类。 但是您也可以具有构造函数参数。
另外,我不确定当相关对象具有不同的构造函数时该怎么办。
请告诉我,SimpleCarFactory中的哪些方法有资格遵循简单工厂模式?
亲切的问候,
我将创建一个CarOptions
对象并使用它,而不是使用许多不同的方法。
public class CarOptions {
private String color;
private CarType carType;
public String getColor() {
return this.color;
}
public void setColor(String color) {
this.color = color;
}
public CarType getCarType() {
return this.carType;
}
public void setCarType(CarType carType) {
this.carType = carType;
}
}
然后是一个简单的makeCar
方法,该方法采用CarOptions
对象。
public Car makeCar(CarOptions options) {
switch (options.getCarType()) {
case AUDI:
return new Audi(options.getColor());
case BMW:
return new Bmw(options.getColor());
default:
throw new RuntimeException("No such car type!");
}
}
这样做的好处是您可以创建BMWCarOptions
类:
public class BMWCarOptions extends CarOptions {
private boolean hasXDrive;
public boolean getHasXDrive() {
return this.hasXDrive;
}
public void setHasXDrive(boolean hasXDrive) {
this.hasXDrive = hasXDrive;
}
}
然后,您仍然可以将其传递给makeCar
方法。
“他们有效吗?”是的。
“他们是最优的”吗?
您不会使方法过载,我认为这将有助于解决您的问题。
public Car makeCar(CarType carType)
throws NoCarExistsException
public Car makeCar(CarType carType, Color color)
throws NoCarExistsException
public Car makeCar(CarType carType, Color color, Options options)
throws NoCarExistsException
// where Options is a container class with hashmap
// (or one of many other valid impl. possibilities) with all the options.
并且只有“此选项组合是否存在”的所有逻辑都在出厂逻辑中即可。
也可以将“颜色”作为“选项”。
注意:这样做的好处是,工厂的用户可以列出所需的选项,然后获得汽车或例外。 使用起来要简单得多,但是意味着逻辑必须存在于Factory中(我应该说应该在其中),而不是依赖于用户必须编写其他逻辑才能进入工厂。
这完全取决于您的工厂将要使用什么。
1)如果要将这个工厂传递给某个通用实例化器,那么您的工厂必须实现该实例化器使用的所有工厂通用的一些接口。 该接口可能只有一种具有通用选项的方法:
public interface CarFactory {
Car makeCar(CarOptions options);
}
2)如果您打算从代码的不同部分“手动”调用工厂,那么我会说您的方法是正确的。 makeAudi("red", true)
比makeCar(new CarOptions(CarType.AUDI, "red", ...))
更具可读性。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.