Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Paul Clapham
  • Jeanne Boyarsky
  • Knute Snortum
Sheriffs:
  • Liutauras Vilda
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Joe Ess
  • salvin francis
  • fred rosenberger

How do you decide when to use a method or make a new class?

 
Ranch Hand
Posts: 205
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I want to let users modify a baseball team in 4 ways. 1) Modify the description of the team, 2) Modify the batting order of the team, 3) Modify one player on the team and 4) Modify one statistic for all of the players on the team. My question is do I 1) make a method for the Team class which modifies the team using four other methods, 2) make a TeamModifier class which modifies the team using four methods 3) make a Modifier interface and have a DescriptionOrderModifier class, a BattingOrderModifier class, a StatisticModifier class and a PlayerModifier class which implement the Modifier interface and have a Modifier class use an Abstract Factory and polymorphism to implement it or 4) something else. As I write the question #3 seems to fit what I have been learning but any ideas would be appreciated. Thanks!
 
Ranch Hand
Posts: 952
4
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Read about design principles like SOLID, KISS, SLAP. It will help you to decide.
 
author
Posts: 42
1
Eclipse IDE Spring Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 5167
11
Netbeans IDE Opera Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kendall. please BeForthrightWhenCrossPostingToOtherSites
http://www.java-forums.org/new-java/94814-how-decide-when-use-methods-classes.html
 
Kendall Ponder
Ranch Hand
Posts: 205
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Darryl Burke wrote:Kendall. please BeForthrightWhenCrossPostingToOtherSites
http://www.java-forums.org/new-java/94814-how-decide-when-use-methods-classes.html



Is it against the rules to post to other sites? I just wanted a variety of opinions. I did not intend to break any rules. Sorry.
 
Sheriff
Posts: 21839
105
Eclipse IDE Spring VI Editor Chrome Java Ubuntu Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Kendall Ponder
Ranch Hand
Posts: 205
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.



I will do that in the future. This was the kind of question that I thought would not have a black and white answer so I just wanted to hear as many opinions as possible.
 
Kendall Ponder
Ranch Hand
Posts: 205
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tushar Goel wrote:Read about design principles like SOLID, KISS, SLAP. It will help you to decide.


I will check these out. Thanks!
 
Kendall Ponder
Ranch Hand
Posts: 205
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.



Thanks for your response. I agree with all you said and that is how I have it coded at present but I have read where you should keep the classes small and do one thing so I wondered if I should break it up. I think the one thing the Team object does is modify the team which is what these methods do but I wanted to hear other ideas. Thanks!
 
I would challenge you to a battle of wits, but I see you are unarmed - shakespear. Unarmed tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!