From what I've learned, an object should only know about itself and it's relation with its neighbors and not more. What I'm confused about is I think that an object should need to know a little about the running environment. For example, when implementing MVC pattern in controller, the controller should be stateless because it is recreated every time a request comes in, and we can run the computation in a single thread, because we don't need to worry about UI responsiveness like GUI applications. In GUI applications, we can save the states in the controller and we can't do the execution in a single thread because it could make the UI non responsive. These considerations could make great difference in my design, especially because of the threading problem.

When I'm writing a web MVC that is a single threaded environment, I could do it like this:

class Controller{

    public void doSomething(){

        //retrieving data with slow internet connection, patiently wait until the model finished

        int something = model.getSomething();

        view.renderSomething(something);

    }

}

But in GUI applications, I don't think I can do the same. If the model talks to the database or the network, it could disturb the UI thread because of the long running operation. I think the controller needs to know that the model will take a long time to do his job, so my solution would be the controller telling the model to fetch some data asynchronously, and then doing another job until the model notifies the controller when it's done.

So, should I take the execution environment into considerations when designing? Is it possible to design the objects so that they could run in any kind of environment? I don't think that domain objects could be reusable in different kinds of environment since the design could be completely different to suit environment needs.

Hi everybody!

I wrote up what I said about code commenting in a blog post.

I've recently been working through GOOS and I've learned a lot from it. Congratulations on a well-written book. I've been storing my code in the following GitHub repo:

github.com/dchetwynd/GOOS-Auction-Sniper

I'm currently stuck at the end of Chapter 19, the final chapter for the Auction Sniper example. At the end of the chapter I should have been at the stage where all tests were green, but the sniperBidsForMultipleItems() end-to-end test was failing. My GitHub commit where I was left with this single failing end-to-end test was 31ba62fdfd6dfd60a0bd65b41e950107e0959a32. I've since reverted a few commits to return to the last place that I was green. I've then tried again and reached the point where sniperBidsForMultipleItems() first starts failing. This corresponds to my most recent GitHub commit of bd6f752ca7bd3ffabb5809e15338495c68728e48.

In commit bd6f752ca7bd3ffabb5809e15338495c68728e48 I have the following four failing tests:

AuctionMessageTranslatorTest/notifiesAuctionFailedWhenBadMessageReceived()  (unit)

AuctionMessageTranslatorTest/notifiesAuctionFailedWhenEventTypeMissing()  (unit)

AuctionSniperEndToEndTest/notifiesAuctionFailedWhenEventTypeMissing()

AuctionSniperEndToEndTest/sniperBidsForMultipleItems()

The first three of these failures are expected failures, as I have not yet implemented the code for the XMPPFailureReporter. I cannot see why sniperBidsForMultipleItems() is failing for me here though. Even when I implement the remaining code from chapter 19, sniperBidsForMultipleItems() continues to fail for me (GitHub commit 31ba62fdfd6dfd60a0bd65b41e950107e0959a32). This end-to-end test fails at the following statement:

auction1.hasReceivedBid(1098, ApplicationRunner.SNIPER_XMPP_ID);  (line 70 in AuctionSniperEndToEndTest in my code).

If I comment out later assertions for auction1 in sniperBidsForMultipleItems() then the test passes. At the start of this test I have the line:

application.startBiddingIn(auction1, auction2);

If I reverse this line to:

application.startBiddingIn(auction2, auction1);

then instead of the assertions for auction1 failing, the assertions for auction2 start failing from startBiddingIn(). It's as if connecting to the second auction somehow affects the behaviour of the first auction.

What's strangest of all though is when the end-to-end test sniperBidsForMultipleItems() starts failing for me. In AuctionMessageTranslatorTest I have the helper method expectFailureWithMessage(), where this has the following two JMock expectations:

context.checking(new Expectations()

{{

    oneOf(listener).auctionFailed();

    oneOf(failureReporter).cannotTranslateMessage(

        with(ApplicationRunner.SNIPER_ID),

        with(badMessage),

        with(any(Exception.class)));

}});

The sniperBidsForMultipleItems() end-to-end test only starts failing for me when the second of these expectations is added. If I comment out the second JMock expectation (lines 107-110 of my AuctionMessageTranslatorTest code), sniperBidsForMultipleItems() then passes. Adding an extra JMock expectation in a unit test is causing an end-to-end test in a different test file to fail for me. I've examined Steve Freeman's auction sniper code at github.com/sf105/goos-code and I can't see any difference between his code and mine to cause this failure. I'm running Mac OS X 10.8.2 with Eclipse 4.2.1 and JMock 2.6.0.

Has anyone else encountered this same problem? I'd be grateful if someone could pull my GitHub code from either commit 31ba62fdfd6dfd60a0bd65b41e950107e0959a32 or bd6f752ca7bd3ffabb5809e15338495c68728e48 and see if they get the same failure of sniperBidsForMultipleItems().

Thanks for your help and keep up the good work,

Daley

Jim Coplien shares his thoughts on OOP:

I'm trying to understand the role of the SniperLauncher better.  It's in a weird spot between the user interface and the rest of the application.  It's significant in the launching of the application as it's created in the integration layer (the main function).  Is the SniperLauncher's role to provide a well-defined way of manipulating the domain?

Along the same lines, how would one add further SniperLauncher-like functionality such as cancelling an auction?  Would an approach be to have the SniperLauncher inject a well-defined way of updating the sniper or auction?  Wouldn't then the SniperLauncher have a similar role as the main function?

In his TDD Book, Kent Beck said:

Assert First

When should you write the asserts? Try writing them first. Don’t you just love self-similarity?

• Where should you start building a system? With stories you want to be able to tell about the finished system.
• Where should you start writing a bit of functionality? With the tests you want to pass with the finished code.
• Where should you start writing a test? With the asserts that will pass when it is done.

Jim Newkirk introduced me to this technique. When I test assert-first, I find it has a powerful simplifying effect. When you are writing a test, you are solving several problems at once, even if you no longer have to think about the implementation.

• Where does the functionality belong? Is it a modification of an existing method, a new method on an existing class, an existing method name implemented in a new place, or a new class?
• What should the names be called?
• How are you going to check for the right answer?
• What is the right answer?
• What other tests does this test suggest?

Pea-sized brains like mine can’t possibly do a good job of solving all of these problems at once. The two problems from the list that can be easily separated from the rest are, “What is the right answer?” and “How am I going to check?”

Back in 2001 William Wake, author of the Refactoring Workbook  observed and named the Arrange-Act-Assert pattern.

One thing he said was:

You might think that the Arrange is the natural thing to write first, since it comes first.

When I’m systematically working through an object’s behaviors, I may write the Act line first.

But a useful technique I learned from Jim Newkirk is that writing the Assert first is a great place to start. When you have a new behavior you know you want to test, Assert First lets you start by asking “Suppose it worked; how would I be able to tell?” With the Assert in place, you can do what Industrial Logic calls “Frame First” and lean on the IDE to “fill in the blanks.”

The Assert in ‘Arrange, Act and Assert’ is doing State Verification.

Analogously, Jason Gorman, (author, amongst other things of the Test-driven Development Maturity Model ), today posted TDD & Mocks – Working Backwards From Expectations  in which he says that when he does Behaviour Verification, i.e. ‘Arrange, Act and Verify’, he writes the verification first.