Comments on: Application Events: Modeling Selection vs De-Selection as Separate Events?

By: derick.bailey

derick.bailey — Fri, 19 Mar 2010 18:37:39 +0000

@Diego,

my response to your comments turned out to be huge. so i posted it as a new entry on it’s own. http://www.lostechies.com/blogs/derickbailey/archive/2010/03/19/a-response-concerning-semantics-and-intention-revealing-code.aspx

By: Edin

Edin — Thu, 18 Mar 2010 08:04:55 +0000

I would say that at this point there is no big difference between the two options. If you go with option 1, you kind of follow KISS principle, if you go with option 2 then you’re making things explicit which is a good thing also.

By: jOE

jOE — Thu, 18 Mar 2010 04:28:28 +0000

1) Does the current solution work?
2) Why not use full-text to find product codes? Drop downs are evil.

By: Diego

Diego — Wed, 17 Mar 2010 18:16:59 +0000

I don’t have the same concern as you. Passing null back to the listener of the event is better approach. It’s safe in the language, it’s semantics really means “nothing”, it’s easy to check, it’s lightweight (costs an clean IntPtr).

Why would you think the user HAS to know something which he might not know. I think is way more straight to work with null than with empty object (null pattern).

BUT, if still you’re not comfortable passing a null back on Selection event, maybe you could take a look at option construct on F#. Maybe you can have something like this in C#.

By: derick.bailey

derick.bailey — Wed, 17 Mar 2010 17:30:37 +0000

@Dan, @Dennis,

The null object pattern would be a better OO solution, but wouldn’t solve the modeling problem, which is the real problem that I’m trying to address. I do like the null object pattern, though. it solves a lot of OO problems.

@Keith,

an undo of hte command would require a memento pattern as well, but would certainly be a possibility, technically. though in this case, i think it would be overkill. i really don’t need an n-level undo and i’m not really dealing with a command at this point. it really is an event – something has happened and the parent form needs to respond – and not a command – something needs to happen, go do it for me.

@rob,

a single Change event would be a better option for #1. good suggestion on that one.

as for the parent and subscribing to two events… the parent will handle either event as distinct things to respond to. the parent cannot assume either of them firing first or second, or having them fired only once. the parent has to be able to respond to any number of either event as they occur. the good news is that it is far easier to code like this than to assume or expect a certain order for the events.

By: Dennis Doomen

Dennis Doomen — Wed, 17 Mar 2010 15:48:13 +0000

What about using the Null Pattern. You surely need the the rest of the product’s info as well. So maybe you can add a public readonly property called Null that returns a special instance of your view model that represents ‘nothing selected’.

By: Keith Bloom

Keith Bloom — Wed, 17 Mar 2010 15:34:38 +0000

An explicit event must be simpler, otherwise the selection event will be the selection event with a status to specify if it is a de-selection event, which doesn’t sound good.

I have recently read the GOF book and the patterns are running around in my head trying to find a place in some code. I am curious to know if a Command object would work here which has the ability to undo the Command issued. Do you know if this is a common use of the pattern?

By: Dan

Dan — Wed, 17 Mar 2010 15:14:25 +0000

I’m leaning towards option #2 as well…but have you considered using the Null Object Pattern in your original scenario?

By: Rob

Rob — Wed, 17 Mar 2010 15:10:21 +0000

Try thinking about it from the parent side – what interface would you want.

Having two events leaves questions like do I get a deslect event before every select event, to indicate the deselection of the previous event.

I would go for a single event called Change. Then either in the event args or exposed as properties of the control (Sender), you have the “get selected item” / “is there a selected item” logic.

By: Jason Meckley

Jason Meckley — Wed, 17 Mar 2010 15:03:40 +0000

I would go with option 2 as well. you already have event aggregation in place. separating the concerns of “selected” & “de-selected” makes sense.