Hi George,
Fully-OOP is good. Using "as much inheritance, base classes, common methods,
etc as possible" is not good. The purpose of OOP is to make programming
easier, faster, better organized, and more intuitive. Note that none of
these things is any of the things you mentioned wanting to use. That's
because the things you mentioned are tools. Tools do not dictate, nor are
they requirements. If you were going to build a house, and you had a
26-ounce Framing hammer, would you say that you wanted to use the new
Framing hammer as much as possible? Of course not. You really need to use it
as much as necessary.
The difference here is that "OOP" is a set of tools and principles that
defines a methodology for programming. The methodology is good. The tools it
employs are neither good nor bad, except in the context of what you do with
them. The only reason I mention this is that many people have a tendancy to
get too attached to the tools and methodologies, and take their attention
off of the goals/requirements. You can find yourself a good way down the
garden path if you go that way.
The primary principle of OOP is that programming entities should resemble
and be treated as "real-life things." That is, rather than thinking about
the nitty-gritty details of process and data (when designing), think about
all of these as objects. This is the way we humans typically perceive the
world. Data is (almost) always associated with some "real-life" entity. Your
object model should reflect that association.
Another principle is that objects should "mind their own business." That is,
as much as possible, an object should manage itself, rather than being
managed by something else outside of it. This lessens dependencies, allowing
classes to be reused in a wider configuration of apps, and makes the overall
application much simpler. So, for example, a League has a collection of
Teams, a team has a collection of players, and if a player needs his/her
shoe tied, he/she shouldn't have to have a League tie it for him. But on the
other hand, if a Team needs to remove a player, it is not changing the
player, but the Team; therefore, that is an action that is appropriate for a
Team.
So, applying these principles to your requirements:
You have mentioned a number of entities:
League
Team
Player
Goalie
Defender
Attacker
Game
Season
The first 3 items are fairly straightforward . A League has a Collection of
Teams. Note that I didn't say "a league *is* a collection of Teams." There
is an important distinction there. There may be other aspects to a League
that are not specific to Teams. For example, a League's standing is not part
of a team; it is a property of a League. So, I would create a class that
*has* a Collection of Teams.
A Team has a Collection of players. Same story here.
A Player is a player. Now, you have some decisions to make regarding the
"roles" of a player (Goalie, Defender, Attacker). No doubt you're wondering
whether or not to use a base class "Player" and 3 derived classes. Well,
let's walk through that one. Inheritance is useful when you want to extend a
set of common attributes to several sub-classes with unique attributes. It
is useful when you may want to treat any of the derived classes as if they
were the base class (such as referring to a "Goalie" as a "Player" for the
purpose of incorporating it into a Team). However, if a Player can change
their "role" you would not want to use inheritance, as the Player would have
to change type to make the change. Another principle of OOP is that you only
use a type when the type is not expected to change.
On the other hand, you may be talking about some relatively simple
differences here. What makes a Goalie different than an Attacker or a
Defender? (Pardon me for not having played FF before). If the number of
differences is great, a derived class may be a good idea. OTOH, if it
doesn't make a lot of difference, simply setting a property or 2 in the
Player class may do enough.
In the end, you have to weigh all of the conditions, and make a decision.
As for Games and Seasons, that is another difficult issue. A Game is a
process which involves players, but is a temporary process, and may involve
any number of different players (at least any combination of 2 Teams).
Obviously, as there are multiple Games per Season, a Season would suggest a
class that has a collection of Games. A Game might be thought of as having 2
teams, which would indicate 2 properties. However, how do we link each
player in each team with each Game, for the purpose of playing and keeping
statistics? Since each player can play in many games, and each game can have
many players, in a database we would be talking about a "many to many"
relationship. A "many to many" relationship in a database is achieved by
using an intermediate table, which contains 2 columns, each linked to one of
the parent tables, and whatever other columns may be needed. The scoring
statistics sound like one of those things that would be shared between one
class and another, so that detailed performance for each player can be
obtained, as well as summary performance information for each game.
Therefore, I would think that another class called "PlayerPoin ts" (or
something like that) be created, which includes a Player and a Game as
properties, and a number that represents the number of points which that
Player scored in that Game. Since each Player participlates in any number of
Games, each Player could have a Collection of Games played, and the
PlayerPoints would be a Collection of each Game. That way, you could create
properties for both the player and the game that can tally up their scores.
I hope this at least provides some ideas for you to think over.
--
HTH,
Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist
Big thicks are made up of lots of little thins.
<ge************ *@gmail.comwrot e in message
news:11******** *************@s 16g2000cws.goog legroups.com...
Hi all,
I'm looking for some advice on how best to achitect the following
requirement.
I'm basically writing a Fantasy Football (FF) Web site, and would like
to have it fully OO and have it using as much inheritance, base
classes, common methods, etc as possible.
My biggest headache that I cant get my head around is how to handle
teams and players. The basic scenario of requirements is:
There are 1+ FF leagues
Each FF leage hase 1+ teams
Each FF team has 11+ players
Each FF player can be either goalie, defender, attacker
Each FF player has a monetery value
Each FF player has a number of points per game
There are X number of games per season
There are X number of seasons
Each player in a FF Team comes from an actual REAL football player
A real player can only exist in one FF league
A real player can be active or inactive (and as such the FF player
inherits from this)
A real player has a number of points per game (if the player is a FF
player, then for the appropriate game the FF player gets the points)
I can work out some base classes, properties and methods, but would
find some technical architecture advice invaluable. Any and all output
I produce will be shared!
Thanks all!
