After looking at your designs, both your first and third iterations appear to be more elegant designs. However, you mention that you're a student and your professor gave you some feedback. Without knowing exactly what your assignment or the purpose of the class is or more information about what your professor suggested, I would take anything I say below with a grain of salt.
In your first design, you declare your RuleInterface
to be an interface that defines how to handle each player's turn, how to determine if the game is over, and how to determine a winner after the game ends. It seems like that's a valid interface to a family of games that experiences variation. However, depending on the games, you might have duplicated code. I'd agree that the flexibility to change the rules of one game is a good thing, but I'd also argue that code duplication is terrible for defects. If you copy/paste defective code between implementations and one has a bug in it, you now have multiple bugs that need to be fixed in different locations. If you rewrite the implementations at different times, you could introduce defects in different locations. Neither of those is desirable.
Your second design seems rather complex, with a deep inheritance tree. At least, it's deeper than I would expect for solving this type of problem. You're also starting to break up implementation details into other classes. Ultimately, you are modeling and implementing a game. This might be an interesting approach if you were required mix-and-match your rules for determining the results of a move, the end of the game, and a winner, that doesn't seem to be in the requirements that you've mentioned. Your games are well defined sets of rules, and I'd try to encapsulate the games as much as I can into separate entities.
Your third design is one that I like the best. My only concern is that it's not at the right level of abstraction. Right now, you appear to be modeling a turn. I would recommend considering designing the game. Consider that you have players who are making moves on some kind of board, using stones. Your game requires these actors to be present. From there, your algorithm is not doTurn()
but playGame()
, which goes from the initial move to the final move, after which it terminates. After every player's move, it adjusts the state of the game, determines if the game is in a final state, and if it is, determines the winner.
I would recommend taking closer looks at your first and third designs and working with them. It might also help to think in terms of prototypes. What would the clients that use these interfaces look like? Does one design approach make more sense for implementing a client that's actually going to instantiate a game and play the game? You need to realize what it's interacting with. In your particular case, it's the Game
class, and any other associated elements - you can't design in isolation.
Since you mention you're a student, I'd like to share a few things from a time when I was the TA for a software design course:
- Patterns are simply a way of capturing things that have worked in the past, but abstracting them to a point where they can be used in other designs. Each catalog of design patterns gives a name to a pattern, explains its intentions and where it can be used, and situations where it would ultimately constrain your design.
- Design comes with experience. The best way to get good at design isn't to simply focus on the modeling aspects, but realize what goes into the implementation of that model. The most elegant design is useful if it can't easily be implemented or it doesn't fit into the larger design of the system or with other systems.
- Very few designs are "right" or "wrong". As long as the design fulfills the requirements of the system, it can't be wrong. Once there's a mapping from each requirement into some representation of how the system is going to meet that requirement, the design can't be wrong. It's only a qualitative at this point about concepts such as flexibility or reusability or testability or maintainability.
The intent of the strategy pattern according to the GoF is to "define a family of algorithms, encapsulate them and make them interchangeable. The strategy lets algorithms vay independently from client that use it"
In your code you apply this pattern, making a strategy of ContentHandler
that can be declined in different concrete content handling, depending on the requests to pursue.
Problem with the switch approach:
However, in your implementation the serialization depends on the format you want to use. The way you pass a content type, using lots of switch
blocks to produce the appropriate format, will make the code very difficult to maintain: each content handler implementation will have to provide for all kind of formats. Imagine that one day you'd like to add a new format (for example bson) : you'd need to review all the switch
blocks of all your concrete implementation of ContentHandler
. That's a huge work, and clearly does not very well enforce separation of concerns.
Alternative:
But looking at it more closely, you have here an opportunity to add a second level of strategies. Each of your switch block would correspond to a kind of primitive operation on the content to produce the format. It's another family of algorithms. You should hence make the format a strategy as well:
public interface SerialFormatter {
String createStringNode(...);
String openSubbloc(...);
... // you have to analyze your switch blocks to determine the primitives
};
And then regroup all format specific primitives according to this logic:
class JSONFormatter implements SerialFormatter { ... };
class XMLFormatter implements SerialFormatter { ... };
If one day you want to support a new format, just add a new class of this kind.
You then can simplify your serializer logic:
String serializeRequest(Content con, SerialFormatter fmt){
// ....
String s = fmt.openSubbloc ("ID") +
fmt.createStringNode ("Name", con.name() ) +
...
fmt.closeSubbloc("ID");
return s;
}
Conclusion
Design using combination of multiple strategies is sometimes called "policy based design" It is a very powerful approach: with n kind of requests and m format, you'd write m+n classes with single responsibility, instead of writing nm classes (see other answer to your question) or writing n classes and at least nm rather redundant cases
.
Best Answer
In the end, collecting all advice in the comments section, I went with making the Factory an actual Factory, providing it with a dictionary between some parameters like 'User' and a fully qualified namespace + class name.
This way the Factory isn't coupled with the actual strategies, and it actually builds instances instead of just passing an attribute back.
As suggested, the chosen strategy is then placed inside a property on the Context class.