Issue: Where to keep the bowler's delivery, in Bowler or Member?
Discussion: Having it in a Member would be useful because a Bowler might have different deliveries depending on the League. However, that leads to there being two or three possible Members with the same ID. While having two IDs is not a problem for a ArrayList, it could be a problem if I choose some other store for the AbstractBowlingList. With two Members with the same ID values, it is also possible to identify the fact that there are two, and add the delivery to the name when presenting a list of members (as in selecting members for a team). But this creates a problem with the Team objects where the members are stored as the Bowler ID value. How can I tell which Member is on the team? The possibility of having separate Member IDs from the Bowler Ids, but having them seems like it would complicate things even farther.
Keeping the delivery in the Bowler object means that if a Bowler had two or three deliveries, there would be two or three different ID values. Thus the Team object can easily keep track of which Member is on the Team. However, this makes it more difficult to identify when a single individual has multiple entries due to different deliveries. The reason this is important is when selecting a Bowler to be a Member, or selecting a Member to be on a Team, how would the separate identities (deliveries) be displayed? Preferably by showing the delivery (RH, LH, BH) next to the name, but how will the program know when a person has multiple identities, so the delivery will be shown?
One possible way to identify Bowlers with multiple deliveries is to use the USBC ID number. Since each individual should have a separate USBC ID number, if two or three Bowlers (or Members through their link to a Bowler) have the same USBC ID then they must have different deliveries. While some new Bowlers might not have a USBC ID at the start of the season, they should have one several weeks into the season. In other words, a blank USBC ID does not mean that the Bowler has multiple deliveries, just because there will be other blank USBC Ids.
Conclusion: It seems that making different deliveries into different Bowlers is the best solution to this problem. Put the delivery as part of the Bowler. An individual with different deliveries will have multiple Bowler entries. Also include a True/False field to indicate if the Bowler has a different delivery Bowler record so it will be used to determine when the delivery should be included in the name when choosing from a list. When more than one Bowler record exists for the same individual, all Bowler objects associated with that individual will indicate that multiple records exist.