Four blindingly obvious remarks.
(1) Where are the comments? What problem is this actually solving?
Where is the specification? Oh, it's at the *end*, not actually
in the Team class.
(2) name: anObject
name := anObject
and way too many methods like it.
(a) Saying "anObject" is maximally unhelpful. It's even worse than "s"
because that might be a clue that it is a string or symbol. You
might want to read the (now free) book "Smalltalk with Style".
(b) I dislike "setter" methods that let anyone poke absolutely anything
into your object. For example, supposing that name should be a string
-- which is the kind of information that should go in a class comment --
I tend to write methods like this as
name: aString
name := aString asString.
which either puts a string into name or dies trying.
In fact, I would have an instance cra
(3) When I saw "matchplayed matchtied matchlost" I initially expected them
to be Boolean. It would really help if you had a class comment saying
what they are (and what they mean) and/or an 'initialize' method that
sets them to 0. Furthermore, these things are counts, so in English
would have to be matchesPlayed, matchesTied, matchesWon, matchesLost.
But even that is misleading; you might think they were containers
holding Match objects. So I would suggest
winCount lossCount tieCount
and
totalCount
^winCount + lossCount + tieCount
making it *impossible* for totalCount to disagree with the others.
(4) Code like
aTeam matchwon: aTeam matchwon + 1.
aTeam points: aTeam points + 3.
really doesn't treat aTeam like an object.
We note that there are
3 points for a win
1 point for a tie
0 points for a loss
and realise that we can do
totalPoints
^winCount * 3 + tieCount
gotWin
winCount := winCount + 1.
and now we have
aTeam gotWin.
The rule here is "if you want an object to change state, ASK THE OBJECT TO DO IT."
Locked
Tournament.st (14K)