Click here to Skip to main content
13,044,935 members (44,626 online)
Rate this:
Please Sign up or sign in to vote.
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.
basketball, football, hockey puck.

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
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.
Rate this: bad
Please Sign up or sign in to vote.

Solution 2

Attributes in .NET is something completely different: please read on attributes to understand it:[^].

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.

Rate this: bad
Please Sign up or sign in to vote.

Solution 1

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

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month

Advertise | Privacy | Mobile
Web02 | 2.8.170713.1 | Last Updated 11 Apr 2013
Copyright © CodeProject, 1999-2017
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100