October 20th, 2010

Gamer Kero

This entry implements both of the interfaces for my Livejournal posts

Happy birthday to sassy_wench, if she's still around. Haven't heard from any of her personalities in a while.

Today's Bridge: It wasn't a good day for us in the cards, but we had a couple of interesting hands. In one of my favorites, I managed to make 2D with a 4-4 diamond suit and Dan holding four diamonds to the A-K. He treated me kindly, though, leading a side suit when he got in the lead the first time, then leading his low diamond instead of the ace first. That gave me an additional crossruff that just gave me the tricks I needed, plus allowed me to get back to my hand after he ruffed in with the ace. I think we finished with a 4H, easily made with S K-J-x H A-K-x-x D Q-x-x C Q-x-x facing S Q-x-x-x-x H J-x-x-x D x C A-K-x. Dan started with the ace and a low spade, so I won, pulled two rounds of trump (leaving Dan with just the queen), then took a quick count and liked what I got. I pulled the last trump, gave them a diamond trick, then took the rest. Dan's spade lead had set up the guaranteed spade tricks - without that, I may have to try to ruff both diamonds out of my hand. or something, and force Dan to ruff with the queen. I'm pretty sure the contract is guaranteed. But we'd already lost the rubber by then. We raised Paul's 2H pre-empt to 4H while Mike uncertainly put in a single 4D bid, then doubled our 4H. Dan raised him to 5D, and he sure had the hand for it - something like five diamonds and a heart void. Mike had two clubs and two spades to the ace, so we got the two black kings and they got the rest on a crossruff starting at trick five.

Today's Work: I started working on a UML class diagram for my very simple program, when I came upon an interesting dilemma. This process needs to receive and transmit information via our chosen transport mechanism, but we may change that eventually, so I want to encapsulate the information passing and use an interface so it can be easily changed in the future without having to change anything else in the process. That's simple enough. The problem is that separating those functions into two classes, in the simplest way, requires creating two of a resource that I only need or want one of. I really don't want to duplicate it, so I need both of them to use the same one. I could make a singleton out of it, but that's yet another class, and it seems like overkill for this application. Another option would be to make a single class that implements both interfaces, and the main class will just have to know that it has to make two references to a single object for this particular implementation. That breaks the abstraction a bit, but I think it's acceptable. The third option is just to design it to be a single class from the start, which provides both interfaces, and that one can incorporate two different classes while still containing any shared information that they'll need, or just have all the functionality for all communication self-contained. I figure I'll just ask the rest of the group which they recommend, since every process is going to need to have the same elements, so I expect everyone will want to pick the same best way to handle this situation.

Collapse )

Collapse )