Page 1 of 1

Sports tournament (classes design)

Posted: Wed Aug 08, 2007 10:04 pm
by jmberrueta
Hi, I am working on some PHP classes (persisted into a MySQL database) to manage a sports tournament, but I have some doubts on how some things should be designed.

If I have the following classes:
- Country
- Team
- Cup
- SportsManager

One approach I thought of could be that each Cup would have as a member a list of Teams, and it's Country. Then I would provide the SportsManager with getCups(), getCupsByCountry(), etc.

This design may be helpfull when using the class, but I don't know if is performant. For example, if I want to list the cups in a menu providing a link to each cup, if I use getCups() the Cup classes would be returned with tons of info I won't need in that particular page, therefore, wasting time querying the database.

So... should I pay more attention to easyness of usage or performance? Is there another way of doing such thing without creating methods in the SportsManager such as getCupLinks() or getCupId() and getCupName() to display the menu links without instantiating the whole class?

Thanks in advance

Posted: Thu Aug 09, 2007 2:11 am
by Christopher
My initial response is to give TDD a try at the problem. Start out with the most important and simplest case then grow the system from there. The question is where to start. I think your Country, Cup and Team make sense. I am not sure what SportsManager is. I suspect that it is a conceptual box you created to put the part of the design that you don't understand yet. If you don't understand it -- don't design or build it (yet).

Given your description I think I might start with something simple that finds Countries. That's probably the only thing you know about your SportsManager. A simple Gateway class that can find one or more Countries. A Country in turn can find Cups and a Cup can find a Team. Whether you put the Gateway functionality in these classes or have separate Gateway classes is what you will need to explore. But building that gets you the basic functionality. That's all manual loading, which may work for you. You will then need to decide whether you need to automate any of this loading. It starts to sound like a lightweight O/RM system.

Posted: Thu Aug 09, 2007 3:24 am
by Ollie Saunders
Worry about performance once you've got it working.

Posted: Thu Aug 09, 2007 10:40 pm
by wei
May by analysing the data first, see what sort of entity relationships are required. So, try to design the database first, e.g., A team probably requires a team name, and other details, find a candidate key (team name?) or use a surrogate key (team id), etc. Once the database is designed, the object design follows readily (although not always straight forward).

Posted: Sun Aug 12, 2007 11:08 pm
by jmberrueta
ole wrote:Worry about performance once you've got it working.
Haha! exactly what I was hoping to hear, but I didn't know if I it was correct really to do so or just a mere hope.

I've seen on some other posts (ie. "How many include/reuire , and its effect on PHP script speed") this same idea of 'don't let performance mess your design', and I guess that in case I have performance issues small design changes would be able to solve them.

Thanks evereyone for your answers