12,395,183 members (60,854 online)
Rate this:
See more: , +
If I have 3 classes:

1. Team
2. Player
3. ball

and each have a few types:

backetball team, football team, hokcey team.
basketball player, football player, hockey player.

would i inlcuded these types as attributes in a class or would they have a class of there own and be inherited in to the above classes?

Also, im confused with the relationships. I know these facts:

1.A team needs at least one player and can have many players.
2.A player ccan onlyy have one team.
3.A player can handle a ball many times.
4.A ball can be handled by many players, but only one at a time.

I have the team to player relationship as composition.
I also have the player to ball relationship as aggregation as its options.

Is this correct or can it be done differently?
Posted 11-Apr-13 6:02am
Updated 11-Apr-13 6:49am
v2
richcb 11-Apr-13 12:04pm

I would make the sports be the main classes and have the others inherit from them. Each sport has a team, player, and ball.
TOMT12345 11-Apr-13 12:13pm

So 3 classes for basketall, football and hockey which inherit team, player and ball. Or one class sport with the attributes basketball, football and hockey?
richcb 11-Apr-13 12:17pm

A class for each sport, so if there are three sports then there will be three classes. The sport class can have the team, player, and ball properties.
Sergey Alexandrovich Kryukov 11-Apr-13 12:17pm

Thank you for posting it as a valid question.
Please understand: we are really overwhelmed with non-questions, so I try to remove everything which cannot classify as a question.

Thank you for understanding.
—SA

Rate this:

## Solution 2

Attributes in .NET is something completely different: please read on attributes to understand it: http://msdn.microsoft.com/en-us/library/z0w1kczw%28v=vs.110%29.aspx[^].

What you call "attributes" are more like the UML meaning of this word (do you know UML?). In .NET, the attributes in UML sense are implemented as non-private properties (and using fields is considered bad style; the fields should be used only inside class or to back properties).

In case of relationships between class instances you mean, like composition/aggregation, etc (managed systems highly blur the difference, you use the references to different instances as the properties of your classes. You need to understand reference types very clearly, in particular, you need to understand this: you will have several references (from different class instances) to the same reference-type object.

—SA
Rate this:

## Solution 1

In my opinion both the alternatives are viable. You should investigate the usage scenarios to discover what is the cleanest implementation.

Top Experts
Last 24hrsThis month
 OriginalGriff 215 ppolymorphe 165 Richard Deeming 120 Jochen Arndt 110 Richard MacCutchan 90
 OriginalGriff 5,998 Karthik Bangalore 2,382 ppolymorphe 2,350 F-ES Sitecore 1,877 Richard MacCutchan 1,707