 |
.. (לתיקייה המכילה) | |
What should be the type of the arguments for the methods in the assignment? | |
| It is up to you to decide. Any reasonable decision is OK, but obviously there are better choices than others! |
In the given table, how come Maccabi Nazareth has got only 17 points while it won 5 games and had 5 drawn games? this sums to 20 points! | |
| Right. Maccabi Nazareth was punished for something they did by reduction of 3 points. You may ignore such cases. |
[BUG FIX, v1.00] Shouldn't Bnei Sakhnin have 29 points and Ashdod FC have 30 points? | |
| Right, fixed in v1.01. |
[BUG FIX, v1.00] for class game there are two methods using the same prototype | |
| Correct, the method names were changed in v1.01 |
[BUG FIX, v1.00] in class Game the first method, shouldn't the method's operands have different names ? | |
| That's right, fixed in v1.01. |
can we assume correct input I.e. not test every method's input etc.? | |
| Yes. |
whats the difference between a league and a season? | |
|
Roughly speaking, a league is combination of a group of teams, scoring system, some rules regarding how many and in what order games are played, how the teams' location is set, which teams leave the league, which teams play in UEFA tournaments (if any) etc. A season can be regarded as the period of time in which the league's games are played. A season is the period of time in which the league's games are played. A season begins with all teams starting from a "NULL" position (0 points, 0 wins, draws and losses, etc.), and ends after all teams finished their games, and by setting the champion, the teams that leave the league, etc. Note that a champion is decided per season. I've created only one class, named "League", that is actually a combination of both terms. The reason is that there might be changes between one season to another in the league's structure (one obvious example: the participating teams), so both a league and a season are closely related. It is possible to distinguish a season from a league and you are welcome to do so if you wish. For the purpose of this assignment - the given design is enough. |
[BUG FIX v1.01] Aren't Team's "scoreAt: aRound atSeason: aSeason" and "resultsInWeek: aWeek ofSeason: aSeason" methods the same? | |
| Right, discard the first one (fixed in v1.02). |
I am still a bit nuclear as | |
|
For the sake of the assignment, the class League represents both a league and a season (as defined in the FAQ). When you pass a "season" as an argument to one of Team's methods, the argument actually has to describe both the season (e.g. "'01-'02") and the league (e.g. "Israeli premier league"). Note that in our case there's only one type of league (Israeli premier league), but in the general case there may be more than one league (e.g. "Israeli National league", which is the league that comes right after the premier league). For example: Let's assume that you have chosen the argument aSeason at Team's "winsAt: aSeason" method to be a String (this is in no way a recommendation to do so!), then an argument structure may look like: '<season> <league>' (e.g. '02-03 Israeli premier league'). Teams participate in at least one league every season. For example: the first 10 teams in the premier league of season '02-'03 also participate in the premier league of '03-'04. Teams may also participate in more than one league at the same season, but this only concerns you at the point in which you should not assume that a team plays in one league only (e.g. in the above example accept the season only and assume automatically that this is the Israeli premier league). I do not expect you to store the history of a team for all its seasons in the premier league. This is a possibility, of course, but I think there is a much better one. |
Do we have to have all our methods' arguments names begin with an 'a'? | |
| This is the convention, please use it as well. |
in WeekGames' method gameOf:, what do you mean by "score"? Is it the number of goals of the team at this week or the points it gets this week according to win/loss...? | |
|
This is: the number of goals the team scored and the number of scores its oponent scored, plus any other relevant info you can think of (who's the home and the visiting team, etc.). For instance: assuming that the team lost 0-3, then the returned value should show this. Note that a team may be both the home team and the visiting team, so 0-3 does not necessary mean that the team lost! you have to overcome this "somehow" (hint: all you have to do is to return the right object :-) |
in League's method results: should it return the number of goals or all possible information of this team? | |
| You have to return the details about all games held at the given week, at least the participating teams in each game, who's the visiting and the home team, and the number of goals each team scored. |
When we are asked to return something in some method, do we have to print it to the standard output? | |
| Unless there is a specific requirement in the method's description, you shouldn't. Return the information, and let the caller decide what (s)he would like to do with it. |
in League's method results: aWeek it says that aWeek can be any integer between 1 and the number of games in a season. Did you mean that it should be an Integer between 1 and the number of WEEKS in a season? | |
| Yes. |
[BUG FIX, v1.03] Can you explain a little more about League's method "standings"? what exactly should be its output? | |
| This method is not well defined. It should print the standings of the league to the standard output (fixed in v1.04). |
Does "round" in the assignment actually means "week"? | |
| Yes. Round 7 = week 7 = each team played 7 games so far. |
Can we assume that each team plays only once on each week? | |
| Yes. |
Do we have to print the table in a descending order? | |
| Yes, that's the most comprehensive way to do it... |
What should be the returned value of Game::homeTeam/visitingTeam? should it be the name as a String or an object of a Class Team? | |
| It is up to you to decide: pick the best thing you can think of. Note that this can be regarded as a design question: your decision will influence the capabilities of the class! |
What's the difference between revealer and inspector in LST? I figure a revealer should return a reference to an object (using ^). What should an inspector return? Should it create a new object and return a reference to it? | |
| For the sake of our assignment, they are the same. Both should return a reference to an object; if someone wants to copy an object, (s)he should use the proper method. |
How far should we stick to your design? can we change it if we think there is a better thing that can be done? for example: we think that a parent class for League will make the design more reusable, since adding new leagues will be easy; can we go for it? | |
|
My design can be regarded as a suggestion; if you think you can do a better thing - go for it! the above suggestion is good. I tried to make a simple (but still "meaningful") design, since practicing LST for the first time is annoying enough and I did not want you to write too much code; if you feel like it - you can try to improve the design (and maybe get a bonus for doing so :-). |
While executing a sorting method that sorts the league's standing, LST suddenly shuts down without warning. What could be the reason? | |
|
What happens is that LST explodes, due to limited amount of objects it can handle and the lack of proper garbage collection. You can do one of two: - Take a smaller league (with fewer teams), and test on very few weeks - Try to make your sort algorithm more cost effective in terms of objects it creates; note that loops in LST usually implemented as recursive methods, which creates a lot of objects. See what you can do. In any case - if you have to do something due to LST limitations, state it explicitly in the code. |