0

I am in a bit of a jam in deciding how to structure my class. What I have is a baseball player class and necessary attributes of:

  • Player ID (a key from a DB)
  • Last name
  • First name
  • Team
  • Position
  • Opponent
  • about 10 or 11 stats (historical)
  • about 10 or 11 stats (projected)
  • pitcher matchup
  • weather
  • ... and a few more

Some things to break this down a little:

1) put stats in dictionaries

2) make a team class that can hold general info common for all players on the team like weather and pitcher match up.

But, I still have 10 attributes after this.

Seeing this (Class with too many parameters: better design strategy?) has given me a couple ideas but don't know if they're ideal.

1) Use a dictionary - But then wouldn't be able to use methods to calculate stats (or would have to use separate functions)

2) Use args/kwargs - But from what I can gather, those seem to be for variable amounts of parameters, and all of my parameters will be required.

3) Breaking up into smaller classes - I have broken it up a bit already, but don't know if I can any further.

Is there a better way to build this rather than having a class with a bunch of parameters listed out?

Community
  • 1
  • 1
user4496157
  • 13
  • 4
  • 1
    using args/kwargs isn't only for variable amounts of parameters. and using a dictionary wouldn't keep you from being able to use methods or calculate stats. – abcd Apr 22 '15 at 22:14

1 Answers1

0

If you think about this from the perspective of database design, it would probably be odd to have a BaseballPlayer object that has the following parameters:

  • Team
  • Position
  • Opponent
  • about 10 or 11 stats (historical)
  • about 10 or 11 stats (projected)
  • pitcher matchup
  • weather

Because there are certain things associated with a particular BaseballPlayer which remain relatively fixed, such as name, etc., but these other things are fluid and transitory.

If you were designing this as an application with various database tables, then, it's possible that each of the things listed here would represent a separate table, and the BaseballPlayer's relationship with these other tables amount to current and former Team, etc.

Thus, I would probably break up the problem into more classes, including a StatsClass and a Team class (which is probably what an Opponent really is...).

But it all depends what you would like to do. Usually when you are bending over backwards to cram data into a structure or doing the same to get it back out, the design could be reworked to make your job easier.

erewok
  • 7,555
  • 3
  • 33
  • 45
  • Yeah I was going to put anything that was the same within the team into the team class (opponent, pitcher matchup, weather, ... ) and then have the team object be an attribute of the player. It was still cumbersome after this but I hadn't thought about breaking it up further as far as a stats class. I suppose if I were to isolate those, it would make the Player class much cleaner I think. – user4496157 Apr 23 '15 at 00:26