SniperLauncher Role

[jmis]

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?

[Steve Freeman]

On 16 Feb 2013, at 19:39, jmis wrote:
> 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?

It's an insulating layer between the UI and the Auction implementation. The interface it implements allows the UI not to know about how auctions are actually joined for an item, and the SniperLauncher doesn't need to know anything about the clients that call it. Our original plan, before we ran out of time, was to convert to a web UI and show how code such as the SniperLauncher would not have to change.

> 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?

The SniperLauncher registers a new AuctionSniper with a SniperCollection. In our case, that's in the UI, so the UI knows how to find the sniper for an item and talk to it. We can't tell from inside the SniperLauncher, but there could be other collectors that listen for new auctions.

S.

Steve Freeman

Winner of the Agile Alliance Gordon Pask award 2006
Book: http://www.growing-object-oriented-software.com

+44 797 179 4105
Twitter: @sf105
Higher Order Logic Limited
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 7522677

[jmis]

Thank you for the reply Steve.  There's still a piece that's unclear to me.  Let me try to explain my thoughts.

I want to add the ability to cancel the sniping of an auction.  The cancel sniping functionality is only applicable if you're currently sniping an auction.  I don't want the UI to implicitly know when the cancel functionality is available.  That means I can't add the cancel functionality to the SniperLauncher because cancelling depends on joining.  We still want to maintain an insulation layer so the UI doesn't need to know about the rest of the application.  How can we make the cancel functionality accessible to the UI only when it's valid (i.e. after an auction is joined)?

The SniperLauncher is created within the integration layer (i.e.  the main function).  It seems to me that we would need to have a second integration layer to bind together part of the UI, the new cancel auction insulation layer and the rest of the application.  Is this accurate?

[Nat Pryce]

I would add cancellation to the AuctionSniper itself. The UI is
holding on to snipers so that it can listen to their state changes.
If the user wants to cancel an auction, the UI can tell the sniper to
stop sniping and it can announce an event when it's finished
disconnecting from the auction, at which point the UI can remove the
sniper from the view.

--Nat

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Growing Object-Oriented Software" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to growing-object-oriente...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
http://www.natpryce.com

[jmis]

I'll give that a try Nat.  I had something similar implemented but I wanted to take a step back to think about roles.