Darryl Burke wrote:Kendall. please BeForthrightWhenCrossPostingToOtherSites
Rob Spoor wrote:There's no problem if you cross post, as long as you inform us (and the other site(s)) that you have cross posted. It can be annoying if we spend a lot of time answering your question, only to find out the same answer was already given elsewhere.
Tushar Goel wrote:Read about design principles like SOLID, KISS, SLAP. It will help you to decide.
Esteban Herrera wrote:Your option number one (or a variation of this) seems to me the best one. These are my thoughts:
- I assume you have a Team class and a Player class (and maybe a Statistic class).
- I also assume that Team has a collection of Players and this class has a collection of Statistics.
- Design is not always white or black; it depends on the circumstances, but always prefer simple solutions (KISS principle). Is the abstract factory really justified? We shouldn't implement design patterns just for the sake of them. Is really worth to implement so many classes? Is the system going to implement more behaviors like these in the future?
- I don't think so. The modifications seem too simple that seems better to implement them with a method. I think you should use factory/strategy or whatever pattern only if you need flexibility for future changes.
- Behavior should be placed where it belongs:
1) Modify the description of the team. What class has the data of a team? This sound like a method of Team.
2) Modify the batting order of the team. What class has this information? Again, this sound like a method of Team.
3) Modify one player on the team. What class has this information? Again, this sound like a method of Team.
4) Modify one statistic for all of the players on the team. This seems a little more complex. What class has the statistic information? Sounds like Player has this info. So maybe Player should have one method to modify the statistics and another to get the players that belongs to a team (you can place this method on the Team class also, it depends how you want to access this information).
- If you want, you can use a Facade (like the TeamModifier class of your second option, but calling methods on the Team class) to protect your client code from changes of this new functionality.
Anyway, these are just my thoughts. As Tushar said, you should read about design principles and take into account your priorities (what do you want? Easy to understand, flexibility for change, easy of testing, etc.) to decide on one approach.