OO design question?

[Garrett Rowe]

I'm suprised that the decision was made to put isDeuce() and hasAdvantage() in the presentation class and not as a state of the TennisGame class. I'm interested to see if it will reamin this way. I'm also interested to see how a 6-6 set score resulting in a tie breaker will be handled. Keep the posts coming guys... take off work if you have to, this good stuff.

[Frank Carver]

Thanks Garrett. I was beginning to wonder if anyone else was reading all this stuff

[Frank Carver]

And as a side note, my connection to sourceforge subversion seems to be working again. My latest changes have been checked in, now.

[Ilja Preuss]

Originally posted by Frank Carver:
And as a side note, my connection to sourceforge subversion seems to be working again. My latest changes have been checked in, now.

That's great to hear!

[Ilja Preuss]

Originally posted by Garrett Rowe:
I'm suprised that the decision was made to put isDeuce() and hasAdvantage() in the presentation class and not as a state of the TennisGame class. I'm interested to see if it will reamin this way.

Same here. To me it seems that a Deuce is not just some presentation issue, but a "business rule". When I think about a tennis score, I don't think about it as "12-13, which should be displayed as 'Advantage Carver'".

In fact, I think more about it like a simple state machine. Perhaps at some time in the future I will just create a branch of the code to try that idea and see what discussions arise.

But for now, my next step will be to make the system actually usable for our customer - we have postponed that for too long already.

Unless someone else grabs the keyboard before me, of course.

[Frank Carver]

I guess there are plenty of ways of viewing this problem. To me, the display of stuff like "deuce" and "advantage" is quite separate from the victory conditions for a game, which could probably be simplified to someting like:

win if at least one score is at least 3 AND one player has at least two more points than the other.

The thing about this is that it says nothing about "deuce" or "advantage", or the stages and progression of scoring, merely who wins. It's a simple predicate.

I can easily imagine that Set and Match have similar predicates, just with different victory conditions.

[Frank Carver]

Ilja wrote: When I think about a tennis score, I don't think about it as "12-13, which should be displayed as 'Advantage Carver'"

but previously, Ilja also wrote: your design so far very much looks to me like you tried to "model the real world". This is a very common approach, but in my opinion one that leads to inferior software systems. The purpose of a software design is to make a system easy to develop and maintain, so the forces of the code are much more important.

[Ilja Preuss]

cardmeeting is now only again, and I created a public space for us:

http://cardmeeting.com/Launch?username=anonymous&newspace=JavaRanch+TennisMatch+Design

You will need a Java plugin for your browser to run it (I didn't get it to run in IE, but Firefox worked smoothly).

[Frank Carver]

Neat little tool, although the "desktop" feels a little cramped. The cards seem quite large for what they are.

I guess it's intended to run alongside other forms of communication; phone, IM, netmeeting, etc. It felt quite "lonely" just messing with cards on my own.

[Ilja Preuss]

Originally posted by Frank Carver:
Neat little tool, although the "desktop" feels a little cramped. The cards seem quite large for what they are.

You can zoom in and out. There is a short manual on the main page.

I guess it's intended to run alongside other forms of communication; phone, IM, netmeeting, etc. It felt quite "lonely" just messing with cards on my own.

Yes, I felt the same way...

[Ilja Preuss]

Originally posted by Frank Carver:
Ilja wrote: When I think about a tennis score, I don't think about it as "12-13, which should be displayed as 'Advantage Carver'"

but previously, Ilja also wrote: your design so far very much looks to me like you tried to "model the real world". This is a very common approach, but in my opinion one that leads to inferior software systems. The purpose of a software design is to make a system easy to develop and maintain, so the forces of the code are much more important.

I don't see a contradiction.

I'm certainly against putting concepts into the code just because they exist in the real world. And we already have some concepts in the code that don't exist in the real world, such as a TennisContest, or a Game notifying a Set.

But the concept of "Deuce" already *is* in the code, no matter where we put it - we simply need it, or so it seems. Putting it close to where people expect it helps in making the system easier to develop and maintain, I would think.

Also, the rule of "win if at least one score is at least 3 AND one player has at least two more points than the other" to me is a major deviation from the original business rule, especially since in tennis a score of 3 doesn't even exist for a regular game. I'm not fully convinced that the simplification in the code warrants this deviation.

But most importantly, I feel that putting the deuce logic into the TennisFormatter simply is a bad design choice. Mostly because the deuce logic and the rest of the formatting logic are going to change at a very different rate - the deuce logic when the rules of the game change, the formatting logic when we want some other form of output (say, voice).

The Single Responsibility Principle nudges us rather strongly to put those two pieces of logic into separate classes, in my not so humble opinion. It doesn't have to be in the TennisGame class, of course - that's just my current best idea, and I'd trust - no, expect - us to find a better place later. (And just to make that clear, I'd expect us to find a much better place together than I would be able to find if I were working on this alone.)

[Frank Carver]

I used to hate such diagreements. I've seen them turn into gloating or bitterness too many times.

These days, I try and use them as a sign that neither approach is entirely right, and that maybe soemthing else is needed.

Of course, I still favour my original approach, but if that is ruled out of the picture, what is left?

In this case, we have me on one side, reluctant to include deuce identification in the current TennisGame (because I can see so many similarities between game, set and match behaviour, and don't really see deuce identification as vital to scoring), and Ilja reluctant to include deuce identification in the current TennisFormatter (because he can see a potential mismatch in change rate).

In practice I think it could actually be more complex than this. I took a quick look around the web for tennis score cards and found (among many others) the following varied examples:

http://grimsbytenniscentre.home.comcast.net/ClubDocuments/LincsScCrd.pdf

http://grimsbytenniscentre.home.comcast.net/ClubDocuments/VetsScoreCard.pdf

http://grimsbytenniscentre.home.comcast.net/ClubDocuments/shorttennisscoresheet.pdf

http://grimsbytenniscentre.home.comcast.net/ClubDocuments/Scoresheet.pdf

http://www.fedcup.com/shared/medialibrary/pdf/original/FC_2348_original.PDF

Even some pocket PC software: http://www.pocketgear.com/software_detail.asp?id=21090&associateid=262&afsrc=1 (animated screen shot at http://www.clubimate.com/pc-9557-389-tennis-scorecard.aspx )

Finally, just for fun, I also found a bit of "deja vu" : http://forum.java.sun.com/thread.jspa?threadID=754512&tstart=0

( I guess a question here gets a more interesting answer )

The upshot of this bit of research seems to be that both the scoring rules and the display format are actually quite variable. We need to avoid design choices which lock the application too closely to a particular interpretation.

So, why not break the stalemate by introducing an extra level between the current game and formatter. Maybe using something like a decorator/adapter to decouple the concepts:

The current TennisGame remains (for the moment at least) responsible for storing, counting and resetting points. The new intermediate level takes responsibility for determining wins (and other states as necessary) and notifying listeners of state changes. The top (formatter) level observes the state of the intermediate level and converts it to text/graphics as appropriate.

This even seems to sneak up on another somewhat thorny problem, that of names vs symbols. Player names seem a natural fit for the formatter level, progress-specific player symbols such as Player.ONE, Player.SERVER or whatever are probably best suited to the new intermediate level, and the bottom scorer level can just manage an arbitrary collection of scores keyed by an opaque object.

All the usual TDD caveats apply, everything is subject to change later if a better design develops, etc.

Does this sound like a way forward?

[Ilja Preuss]

Yes, I already thought a little bit in that direction, too.

Unfortunately, my harddisk crashed horribly, and it probably will take me another one to two days to get into shape again. So I have to ask you for some patience, sorry...

[Shivani Chandna]

This discussion can be a case study for any one attempting to thinking of doing a "Test driven designing".

I would certainely like to go through all the discussions that have taken place , for learning more on it... Is it possible to have one single doc - with all discussions and code inputs that have taken place?

Can this be done for the user community and added as a tutorial ?

Thank you so much,
Shivani.

[Ilja Preuss]

Originally posted by Shivani Chandna:
This discussion can be a case study for any one attempting to thinking of doing a "Test driven designing".

I would certainely like to go through all the discussions that have taken place , for learning more on it... Is it possible to have one single doc - with all discussions and code inputs that have taken place?

How would that be different from this thread?

[Shivani Chandna]

I thought that the code was posted in sourceforge project - some other repository that you two are using?

Perhaps, I assumed that - Not all the code is posted in this thread ...
Correct me?

Regards,
Shivani.

[Ilja Preuss]

You can browse the complete code at http://svn.sourceforge.net/viewvc/jfcfixtures/JavaRanch_TennisMatch/trunk/ - even every version of the code since we are using the repository, by changing the revision number.

Hope this helps.

[Stan James]

Can we download it all at once? The help said there MIGHT be an icon for a tarball.

[Ilja Preuss]

Originally posted by Stan James:
Can we download it all at once? The help said there MIGHT be an icon for a tarball.

I don't know.

You could of course use a svn client to get the code. The repository URL is https://svn.sourceforge.net/svnroot/jfcfixtures/JavaRanch_TennisMatch/trunk/

For windows, TortoiseSvn is nice.

[Fintan Conway]

Originally posted by Frank Carver:

This even seems to sneak up on another somewhat thorny problem, that of names vs symbols. Player names seem a natural fit for the formatter level, progress-specific player symbols such as Player.ONE, Player.SERVER or whatever are probably best suited to the new intermediate level, and the bottom scorer level can just manage an arbitrary collection of scores keyed by an opaque object.

Could this be solved by having a mapping of player names (String representation) to the enum in this intermediate layer?

HashMap<Player, String> players

When the customer enters the players names in the UI they are assigned to Player.ONE and Player.TWO in the intermediate layer. Player.ONE and Player.TWO are then used in the lower "business logic" layers / classes.
E.g.

addPlayers(String player1, String player2) {
    intermediate.mapPlayers(player1, player2);

in intermediate layer :

HashMap<Player, String> players = new HashMap<Player, String>();
mapPlayers(String player1, String player2) {
    players.put(Player.ONE, player1);
    players.put(Player.ONE, player1);
}
HashMap<Player, String> getPlayers() {
    return players;
}

The formatter could have a method like :

fomatPlayer(Player player) {
    return (String)intermediate.getPlayers().get(player);

Regards,

Fintan
[ September 08, 2006: Message edited by: Fintan Conway ]

[Ilja Preuss]

Yes, I think in the final fully fledged app, we would (will?) probably end up with something like that.

[Nachiket Patel]

Priceless!
Learned a lot.

[Sunny Malik]

Amazing guys,,, but I gave up after sometime.
and I have one question, Where is Naseem ? :roll: