正确使用策略模式意味着在上下文(在你的案例类A
)和策略(在你的情况下执行Function
)之间的聚合。
你可以在下面的图片中看到关系(摘自四人帮,Design patterns: elements of reusable object-oriented software)。
下面我已经应用了传统的策略模式的做法,您的问题。在这种情况下,我已经做到这样Function.apply(AbstractForm)
返回List<DataBean>
删除铸造的需要。你当然可以使用泛型来使Function
更灵活。
战略
public interface Function {
List<DataBean> apply(AbstractForm form);
}
语境
public class A {
private Function fetchData; // strategy
public void setStrategy(Function fetchData) { // method for setting the strategy
this.fetchData = fetchData;
}
// precondition: fetchData != null
public Object generateData(AbstractForm form) {
List<DataBean> dataBeans = fetchData.apply(form); // using the strategy
return null; // whatever you want to return
}
}
在这种情况下,扩展类A
时并不需要,因为我们可以通过注入我们setStrategy(Function)
战略(Function
)。但是,我们可以始终将A
扩展为具有预定义策略的伟大对象。
例如:
public class B extends A {
public B() {
setStrategy((form) -> null); // implement your concrete strategy here
}
}
使用工厂方法
由于用于读取很可能需要的数据,并有可能是没有“默认”使用策略,可能永不会改变,工厂方法模式可用于强制创建产品(Function
)。注意类A
现在是抽象的,并且包括工厂方法createFunction()
,然后在子类中实现(例如B
)以创建Function
。
工厂方法模式的设计可以在下面的UML中看到。在这种情况下,我们的产品现在是之前我们的策略(Function
),创作者是A
类,ConcreteCreator是B
类。
创作者
public abstract class A {
private Function fetchData; // product to be used
public class A() {
fetchData = createFunction(); // call factory method
}
protected abstract Function createFunction(); // factory method
// precondition: fetchData != null
public Object generateData(AbstractForm form) {
List<DataBean> dataBeans = fetchData.apply(form); // using the product
return null; // whatever you want to return
}
}
ConcreteCreator
public class B extends A {
@Override
protected Function createFunction() {
return (form) -> null; // return product
}
}
在这种情况下,产品是固定的并且不多变,但是这可以由两个模式混合来克服一起并包括在第一个例子中再次来自A
类。
看到这个tuto也许它可以帮助您:Java 8中的策略设计模式http://www.baeldung.com/java-strategy-pattern –
我们应该如何识别您是否正确地获得了这个想法?发布一段代码的能力并不能说明... – Holger