Reputation: 119
There are a few questions already on Stackoverflow with similar scenarios, but they don't really address my case. I am currently doing some refactoring and would like to make the code more robust, flexible and readable by applying patterns. Here is the task:
I have a class, let's say class A, which applies some logic when setting one of its members. This logic is prone to change, so I would like to externalise it. This is where the strategy pattern would be useful. Also, at some stage I need to filter a list of objects of class A. The filter logic should also be configurable, so the stragey pattern would be handy in this task also. The question is: How do I combine these requirements into the object-oriented design?
My thoughts so far: - Use a factory for objects of type A, that has two strategy objects: SettingMemberStrategy and FilterStrategy. If the concrete factory is implemented as singleton, the two strategy objects need to be specified before objects can be created. - Have two methods on the interface of class A: setMember(value); boolean filtered(). The exact implementation of these methods is determined by the strategies. However, should the object then also carry instances of the strategies?
This approach might work, but it seems a bit overengineered for the task and aesthetically not too pleasing. Could someone hint at a better solution? Thanks a million.
Cheers,
Martin
public interface IA {
setMember();
filter();
}
public class A implements IA {
private String theMember = "";
getMember() { return this.theMember; }
setMember(String input, otherParameters[]) {
// set value for member based on strategy and parameters
}
boolean filter();
// returns yes/no based on whether this class should be filtered
// as per filter strategy
}
public class myFactory {
private FilterStrategy myFilterStrategy;
private MemberStrategy mySetMemberStrategy;
IA createObjectOfClassA() {
a = new A(mySetMemberStrategy, myFilterStrategy);
}
setFilterStrategy(FilterStrategy s) { this.myFilterStrategy = s }
setMemberStrategy(MemberStrategy s) { this.mySetMemberStrategy = s }
}
Upvotes: 3
Views: 3006
Reputation: 1104
This question depends entirely on how you use these objects. My instinct tells me that in most cases you don't need both a factory and a strategy pattern - you would want to choose one or the other, thus simplifying your code.
If for example, you are creating subclasses of object A in your factory, then eliminate the configurable strategy and bake it into your subclasses.
If, however, you don't create subclasses, just have objects with configurable strategies, then eliminate the factory, and just create the objects with the appropriate strategy in their constructor when you need them.
You could also have a combination of the two if you for example create objects based on an input, and use a factory method to give you a proper instance, i.e.
public A MyFactoryMethod(string typeToCreate){
switch(typeToCreate) {
case "AbeforeB":
return new A(new FilterStrategyA(), new MemberStragegyB());
case "allA":
return new A(new FilterA(), new MemberStrategyA());
// etc. etc.
}
}
Upvotes: 1